Très souvent, les développeurs et architectes sont amenés à faire des choix sur les projets : langages, technologies, bibliothèques externes, architectures...
Nous avons remarqué trois problématiques associées à ces choix :
Une Architecture Decision Record (ADR) est un document qui vient adresser ces trois problèmes. Il est fait en équipe et stocké avec la documentation. Il vise d'abord à expliciter le problème et le contexte, puis à lister toutes les solutions possibles. Enfin, il vise à définir des critères discriminants et à attribuer une note à chaque solution, par rapport à chaque critère. Le choix retenu est la solution qui obtient la meilleure note totale.Nous avons généralisé l'usage d'ADR dans nos équipes pour justifier tous les choix qui sortent de l'ordinaire et nous avons déjà quelques success stories : par exemple, nous avons poussé django server side dans un projet, qui a permis de réduire de moitié la charge de travail. En pratique, le temps passé à faire l'ADR est largement rentabilisé et les équipes montent en compétences grâce à l'outil. Nous vous invitons à l'adopter également.
Plusieurs implémentations de Scrum sont tombées dans le même travers, en faisant un focus trop important sur les user stories, et en faisant passer au second plan la notion d'une fonctionnalité. Par conséquent, une équipe peut régulièrement être amenée à enchaîner des user stories, sans avoir une vision globale. Les résultats nuisent beaucoup à la productivité :
Le cœur du développement de la fonctionnalité est réalisé au cours d’un sprint, mais la gestion des cas limites ou de certains sous-parcours peut nécessiter plusieurs sprints. Cela est dû à un manque de vision commune et d'alignement entre le produit, le design et la tech. En effet, les POs manquent souvent de compétences tech pour spécifier l'épique et trouver les cas limites,
Chez BAM, nous avons introduit depuis quelques années un atelier d’une heure, au lancement d'une feature. Cet atelier réunit toutes les parties prenantes pour dessiner un schéma technico-fonctionnel. Avec un langage visuel inspiré de BPMN, nous dessinons tous les comportements utilisateurs, ainsi que leurs impacts techniques.Ce document constitue ensuite une base de départ pour écrire les user stories.
Un schéma partagé entre toutes les équipes permet à la fois de :
Les bénéfices sont flagrants :
A titre d'exemple, sur l’un de nos projets, cet atelier nous a permis de détecter une mécompréhension fonctionnelle qui aurait coûté 5 semaines de retard à l'équipe, si elle avait été détectée au cours de l'implémentation. Nous utilisons cette approche pour toute fonctionnalité complexe et nous vous invitons à la tester sur tous vos projets
Comment réagir immédiatement à la détection de défauts, pour empêcher qu'ils ne se reproduisent à l'avenir ?
Dans le passé, pour chaque apprentissage nous ajoutions une case à cocher dans notre "definition of ready", ce qui alourdissait la gestion. Avec le QRQC, nous trouvons pourquoi un processus a conduit à l'introduction du défaut X par la personne Y, pour créer le standard et la formation manquante.
D'abord développé dans un contexte industriel, le Toyota Production System a permis à Toyota de se hisser au plus haut niveau mondial de qualité, stabilité, et de productivité.
Le Quick Response Quality Control (QRQC) est inspiré des méthodes d'amélioration continue de Toyota. Dès qu'un défaut de qualité est détecté, il est immédiatement analysé par le Tech Leader.
Quelle que soit leur gravité, tous les défauts constituent pour l’équipe des occasions d'apprendre, de standardiser le travail, d'améliorer les outils et la DevX, de communiquer plus clairement, etc.
Nous avons une démarche d'animation autour du QRQC : dojos de formation, présentations de retours d'expérience, par le biais d'un template commun qui facilite les échanges. Cela nous permet d'accélérer la formation des développeurs et Tech Leads et de capitaliser sur l'expérience de chacun en diffusant les apprentissages. Par ailleurs, chaque nouveau défaut est une occasion d’améliorer nos méthodes de travail petit à petit. La difficulté qui découle de cette méthode, si elle n'est pas maîtrisée, est la tendance à mettre en place des actions qui alourdissent le processus de développement. Il faut éviter cette erreur type.
Nous préconisons que tout Tech Lead fasse au moins 2 QRQC par semaine - c'est pour nous la meilleure méthode pour maintenir la formation en continu et la qualité à très haut niveau. Est-ce qu'il faut viser un QRQC pour chaque défaut ? Peut-être, mais il faut trouver le bon équilibre dans la profondeur d'analyse, la taille et la nature des contre-mesures, etc. pour maintenir un bon rythme de formation et la motivation de l'équipe.
Pour les tests e2e en React Native, Detox est en général largement plébiscité. En parallèle, Appium est souvent laissé pour compte, bien qu’il soit utilisé depuis 8 ans par la communauté native. Nous avons identifié plusieurs raisons principales :
Pourtant, une fois que l’on sait utiliser Appium avec Webdriver pour effectuer les opérations essentielles aux tests e2e (scroll, click, attendre une apparition d'éléments), l'écriture de tests devient similaire à Detox. De plus, cela vous permet de bénéficier de l'atout majeur d'Appium : cet outil effectue les tests en mode boîte noire. En d’autres termes, vous pouvez lancer un script de tests Appium sur n'importe quelle app, sans aucun setup préalable. Cela inclut votre release candidate ou même votre app de production depuis les stores. La vitesse d'exécution est supposée être plus lente, mais une étude très poussée contraste cette information.
Nous constatons sur nos projets que les deux fonctionnent. Si vos développeurs ont déjà de l'expérience avec une techno, nous vous encourageons à maintenir son utilisation. Si vos QAs écrivent les tests automatisés, Appium peut leur permettre de le faire sans builder l'app. Vous pouvez privilégier l'excellente documentation de Detox ou son focus sur les applications mobiles.
En moyenne une application est ré-écrite tous les 4 ans. Ainsi, comment architecturer une application pour qu'elle soit facilement testable, maintenable et déployable tout en assurant une intégration rapide de nos futurs besoins fonctionnels sans augmenter le time to market ?
Chaque plateforme (iOS, Android, Flutter, React Native) utilise une approche différente pour gérer la vue d'une application, mais le cœur de l'app reste la logique métier. Dans l’optique de l'isoler pour la protéger des détails d'implémentation et la rendre testable, il convient de :
Robert C. Martin, Jeffrey Palermo et d'autres architectes référents de l'onion architecture et la clean architecture apportent plusieurs recommandations :
Nous avons appliqué ces architectures sur le terrain pour nos projets iOS et Android, ce qui nous a permis d'émettre plusieurs constats :
A ce stade, nos équipes étudient encore l'application de la clean architecture sur nos projets Flutter et React Native. La complexité apportée n'est pas toujours justifiable sur des projets courts et avec des équipes plus juniors. De plus, l'injection de dépendances en Javascript n'est pas simple. On peut cependant tirer profit d'une séparation en domaines métiers et d'une isolation de nos règles métiers via une architecture en couches.
Si votre projet est simple et qu’il ne contient pas de logique métier, l’implémentation d’une clean architecture n'est pas nécessaire. Mais si votre projet contient de nombreuses règles métiers complexes, nous vous recommandons de tester la clean architecture !
La sécurité est une préoccupation au cœur de chaque application mobile.
Ainsi, comment sensibiliser une équipe de développement pour éviter qu’elle ne crée des failles inconsciemment, par manque de connaissance ou par inattention ?
L’une des premières étapes est d'avoir un schéma clair de l'architecture, comme un diagramme C4 de niveau 2 (container).
Ensuite, les équipes sont encouragées à se poser les questions suivantes pour les grandes fonctionnalités de chaque bloc :
Ces questions constituent la base du Central Vulnerability Scoring System (CVSS) : entrées dans un outil comme CVSS calculator, elles produisent une note allant de 0 (pas de risque) à 10 (vulnérabilité critique). Cela présente deux impacts positifs :
Lorsqu'un utilisateur remonte un problème au service client, les informations sont souvent incomplètes ou erronées. Plusieurs cas de figures sont possibles :
Instabug est un outil qui permet de monitorer et de prioriser les problèmes de performance et de stabilité d'une application. Il permet à l'utilisateur final de remonter un problème sur l'application en fournissant tout le contexte associé à celui-ci (logs, requêtes, étapes de reproduction, vidéo).
L'avantage principal est que l'utilisateur peut remonter un problème qui n'est pas visible sur un outil de monitoring classique, ou pour lequel il n'aurait pas appelé le service client.
Il peut afficher la modale de reporting en secouant le téléphone, en prenant une capture d'écran ou cliquant sur un bouton. Depuis cette modale, il peut alors préciser le problème rencontré. Cela permet aussi d'éviter l'interprétation du problème par deux interlocuteurs (l'utilisateur et le service client).
Nous avons eu l'occasion d'utiliser Instabug en production. Cela nous a permis d'obtenir des remontées précises des problèmes rencontrés et de les corriger plus rapidement. Instabug dispose de SDK natifs, React-Native, Flutter, Cordova, Xamarin, Unity et Web. Il n'existe cependant pas d'intégration Expo à ce stade. L'intégration est rapide et il est facilement possible de changer de service. L'outil propose un système de priorité et d'assignation ainsi que des intégrations avec les plateformes classiques comme Trello ou Jira.
Attention cependant, Instabug log tous les payloads https par défaut : nous recommandons de filtrer les données sensibles pour être conforme à la réglementation RGPD.
Aujourd’hui, le développement logiciel est le moteur des entreprises les plus performantes du monde. A titre d’exemple, que retrouvons nous de commun entre Amazon, Tesla et ING ?
La recherche (DORA) mène depuis 2013 une exploration des pratiques de développement, qui recense aujourd'hui plus de 2000 organisations et couvre tous les domaines d'application logiciel. Les découvertes et la recherche ont été publiées dans le livre Accelerate: The Science of Devops.
Cette étude scientifique, fondée sur la donnée brute, montre une corrélation forte entre le succès (productivité, profitabilité, croissance) et quatre métriques clés : la fréquence de mise en production, le taux de mise en production sans erreur, le Lead time pour qu'un code arrive en production, et le Lead time pour corriger un défaut en production.
Dans notre pratique du Lean, nous avons trouvé une vraie résonance dans ces quatre métriques clés, qui promeuvent toutes les boucles de feedback rapide et l'amélioration continue au service du client et des équipes.
La force principale de ce framework est l'approche rigoureuse basée sur les statistiques de nombreuses entreprises qui le soutiennent, et qui donnent une grande légitimité pour convaincre les décideurs. Le point faible du livre, c'est qu'il reste haut niveau et manque d'exemples pratiques.
Nous creusons actuellement le sujet afin de vous fournir une méthode plus concrète à l'avenir, pour optimiser ces métriques. Par exemple, l’approche de Sadao Nomura portée par Dantotsu nous guide beaucoup aussi.
Notre conseil : lire le livre Accelerate, et le tester dans votre contexte. Nous recommandons à tout le monde de s'approprier la théorie, et d'amener les changements par touches.
Pour gérer les flux de données dans nos applications, deux paradigmes s'offrent à nous : l'impératif et le déclaratif.
L’impératif consiste à appeler la donnée depuis le serveur. Cela implique de déterminer à quel moment le fetch des données doit être réalisé, de gérer le retour (succès, cas d'erreur etc.) puis de mettre à jour l'UI en fonction. L’impératif se traduit par un code lourd et verbeux.
Le déclaratif consiste à s'abonner à une ou plusieurs données, puis à indiquer à notre UI de se mettre à jour si une donnée spécifique est modifiée. C'est cette donnée à laquelle on va venir s'abonner qui représente un observable, c'est-à-dire un tuyau dans lequel des événements circulent. Il est possible de combiner ces tuyaux en utilisant des opérateurs, et la gestion de problèmes complexes devient alors plus simple.
Le principal inconvénient de ce paradigme est sa complexité à être pris en main, puisque le modèle mental est très différent du paradigme impératif.
Nous utilisons cette méthode sur nos projets pour des problèmes complexes en nous appuyant sur des librairies telles que RxSwift, RxJava ou Combine.
Face à des risques grandissants en sécurité informatique sur les dernières années, la sécurité des applications mobiles est devenue elle aussi un sujet de préoccupation majeur.
Aussi, il appartient aux équipes de développement de se baser sur des standards existants et modernes en utilisant des librairies simples mais sécurisées dites de "haut niveau".
Parmi les sujets complexes associés à la sécurité, l'authentification représente un enjeu majeur, d’autant plus lorsqu’on passe par un fournisseur externe (réseau social, cloud).
Il est donc important de suivre minutieusement certains standards tels que OAuth2 ou OpenIDConnect, bien qu’il existe encore à ce jour de nombreuses zones d’ombre dans les détails d'implémentation.
A titre d’exemple, le RFC 8252 interdit l'usage des "webviews" dans sa section 8.12, car elles présentent des risques de sécurité et de sérieux problèmes d'ergonomie.
Sur le terrain, nous observons de nombreux projets utiliser des webviews avec un deeplink ou un universal link, ou bien des webviews avec une communication via l'API postMessage(). Ces approches présentent des failles de sécurité.
AppAuth propose un package pour faciliter l'implémentation sécurisée du RFC 8252. Il est facile d’accès : via une librairie iOS et Android ainsi qu'un bridge React Native et Flutter, et permet ainsi de développer plus rapidement une solution plus sécurisée.Nous souhaitons accompagner la prise de conscience de la sécurité côté développement mobile avec des recommandations de librairies, et AppAuth nous semble être une solution intéressante à explorer pour sécuriser l'authentification.
L'implémentation de l'authentification des utilisateurs sur vos apps peut représenter un investissement coûteux en temps, lorsqu’elle est développée de A à Z par vos équipes. Il faut inclure dès le départ un ensemble de mécanismes fonctionnels de type mail de confirmation ou mot de passe oublié et assurer un niveau de sécurité élevé de bout en bout.
Sur nombre de nos projets, nous utilisons Cognito, la solution d'AWS pour l'authentification.
Très simple à mettre en place, elle permet d'implémenter différents cas d'usage simples (comme ceux mentionnés ci-dessus) mais également plus complexes et adaptés à vos besoins, en s'interfaçant avec AWS Lambda ou AWS Gateway.
Cognito autorise également une gestion intrinsèque des rôles sur votre application, qui permet de donner différents niveaux d'accès selon l'utilisateur. Elle gère l'encryption forte des données, nécessaire pour les applications avec fort enjeux de sécurité (ex: secteur de la santé). Enfin, elle permet une implémentation de la 2FA ou du social login ainsi que l'intégration avec un service SSO, en toute simplicité.
Via l'utilisation d'Amplify, Cognito propose également des composants UX à intégrer dans vos applications. Avec un "free tier" à 50 000 utilisateurs, elle est également peu onéreuse.
En revanche, nous avons rencontré quelques problèmes avec le SDK Flutter Cognito. De plus, de manière générale, la documentation d'AWS est parfois confuse et difficile à parcourir, à la différence de documentations très claires, issues de solutions plus onéreuses, comme Auth0.
Nous vous conseillons donc d'évaluer la pertinence de cette solution pour vos besoins. A titre d'exemple, si vos processus d'authentification sont très basiques, une autre solution peut être plus adaptée.
L’une des promesses du mobile est de pouvoir collaborer tout en se déplaçant.
Ainsi, comment gérer les contributions collectives lorsque le réseau laisse à désirer ? Comment résoudre les conflits réseaux, occasionnés lors d'une édition concurrente ?
Ce questionnement complexe nourrit la recherche depuis les années 1990.
Depuis, de nombreux algorithmes ont vu le jour; à leur apogée: les CRDTs.
Une CRDT (Conflict Free Resolve Datatype) est une structure permettant de contenir données et modifications, de sorte à résoudre automatiquement les conflits les plus simples et à accompagner la résolution des conflits complexes ([JSON CRDT, Kleppmann (2017)]).
Les papiers de recherche sont souvent très complexes à comprendre, et encore plus à implémenter. Mais, il existe des librairies prêtes à l'emploi. En voici deux en Javascript:
- Automerge, écrite par Martin Kleppmann, l’auteur du livre "Designing data intensive applications",
- yJS qui implémente un autre algorithme et est plus performant sur des gros documents.
Quoi qu'il en soit, si vous avez des besoins de collaboration asynchrone, nous vous conseillons de regarder du côté des CRDTs.
Pour simplifier le séquencement des tâches techniques d’une user story auprès de développeurs débutants, nous encourageons l’utilisation de Ghost Programming.
Cette technique consiste à les inviter à découper la user story en micro-tâches en amont du développement et à estimer le temps que prendra chaque tâche (5-10 min chacune). Cette estimation est ensuite challengée par les Tech Leaders, qui doivent être sollicités si la durée effective d’une tâche dépasse l’estimation prévue. Cette pratique de programmation présente de nombreux avantages pour des juniors :
Présenter les avantages de cette technique en amont de son implémentation vous permettra d’embarquer vos collaborateurs, tout en évitant un sentiment de contrôle du travail.Après avoir expérimenté le Ghost Programming chez BAM, nous avons observé une accélération de la vitesse de développement ainsi qu’une hausse d’autonomie dans la rédaction de solutions techniques par nos développeurs débutants. Nous vous invitons à généraliser cette pratique qui constitue un puissant instrument de formation et de productivité au sein de vos équipes.
Github Copilot est un assistant de développement qui permet d’écrire du code plus rapidement, en proposant une autocomplétion avec des bouts de code prêts à être utilisés. En se basant sur OpenAI Codex, Github Copilot analyse les commentaires et les noms de fonctions ou variables, pour suggérer une implémentation.
Nous avons regardé avec intérêt les opportunités portées par cet outil, dont l’arrivée a fait le buzz et a suscité des avis très partagés. En le testant chez BAM, nous avons eu de très bons retours sur plusieurs cas d'usage, notamment :
Le retour d’expérience positif sur ces cas d’usage est toutefois nuancé par des recommandations pas toujours pertinentes, voire erronées. Un de nos collaborateurs estime que : "50% des recommandations sont pas mal, 10% sont parfaites, mais que le reste n’est pas pertinent (ex: pas la bonne tech, syntaxe étrange)". Les retours d'autres membres d'équipe divergent, ce qui traduit une forte variabilité des résultats obtenus.
Quelques risques sont bien identifiés par la communauté, mais pas toujours maîtrisés :
Sur cet outil, notre recommandation est un peu mitigée : dans certains cas de figure, Copilot peut vous faire gagner du temps mais les effets long-terme ne sont pas clairs. Peut-être qu'un outil plus précis utilisant la même techno pourrait nous éviter une utilisation massive des libraires de quelques lignes, comme left-pad ? Pour le moment, nous vous invitons à tester Copilot avec prudence, et à étudier les résultats. A noter aussi que quelques concurrents arrivent sur le marché, comme Tabnine ou Amazon Whisperer.
La cryptographie est devenue un enjeu majeur ces dernières années. La hausse du nombre de communications et l’amélioration continue de la puissance de calcul des ordinateurs (et bientôt l'ordinateur quantique) ont conduit aux développements de nouveaux algorithmes.
La première règle à suivre est de ne pas élaborer ni d’implémenter ses propres algorithmes de chiffrement et d'utiliser uniquement les algorithmes développés par les des experts reconnus et audités par des organismes comme NIST.
En 2021, l'OWASP classe la mauvaise utilisation de la cryptographie comme la faille numéro deux. Et sur le terrain, nous confirmons ce classement.
Alors que faire ? Comment choisir le bon algorithme ? Comment bien l'utiliser ?
Libsodium est un projet open source qui propose une bibliothèque de chiffrement. Pour chaque usage (chiffrement, authenticité, sauvegarde de mots de passe, etc.), il existe un algorithme unique, documenté sur le site libsodium.gitbook.io.
Par exemple, la sauvegarde de mot de passe utilise l'algorithme argon2i et est accessible via la fonction sodium_crypto_pwhash. L'algorithme est choisi pour sa sécurité et sa performance, en particulier sur du matériel embarqué moins puissant.
Nous recommandons d'évaluer Libsodium, en la comparant à d’autres solutions. A titre d’exemple, Libsodium est préférable à CryptoKit (iOS) ou Cryptography (Android) car elle présente un bon algorithme pour un cas d'usage, et que sa bibliothèque fait barrage à une mauvaise utilisation. Disposer d’une même bibliothèque sur le mobile et sur le serveur est aussi une garantie de compatibilité. Et si vos besoins ne vous permettent pas de choisir Libsodium, nous vous invitons tout de même à vous inspirer des choix d'algorithme.
Libsodium est une bibliothèque C++ mais il existe également des packages pour React Native, Flutter, iOS et Android.
Il est crucial pour une application de pouvoir authentifier ses utilisateurs. C'est un choix technique critique, qui aura un impact de taille sur la sécurité, l'expérience utilisateur et le coût de développement. Ainsi, il peut être tentant d'utiliser une solution d'authentification tierce mature, qui a travaillé en qualité et en profondeur tous les problèmes types et propose sa solution à un tarif intéressant.
Firebase Authentication est une solution attrayante pour permettre à votre application de résoudre rapidement tous ces problèmes. Nous l'avons utilisé à plusieurs reprises sur différents projets, dont certains à très fort enjeu de sécurité et de confidentialité des données.
Les principaux avantages de cette solution sont sa rapidité d'intégration ainsi que la réputation de son éditeur Google. De plus, elle permet de bénéficier d’une version d’essai gratuite. En l’utilisant, nous avons cependant découvert plusieurs points noirs :
À noter également qu’à ce jour, Firebase ne fonctionne pas en Chine. De plus, nous ne sommes pas encore parvenus à clarifier si la gestion des données personnelles dans Firebase est pleinement conforme au RGPD.
En conclusion, nous pensons qu'il est préférable de s'abstenir d'utiliser Firebase pour l'authentification des utilisateurs. Nous vous invitons à étudier les répercussions sur le long terme et à considérer une autre alternative (ex: Amazon Cognito) ou une implémentation locale, dans la technologie de votre projet (ex: en SSO, AppAuth, ou OAuth)
Retrouvez l'avis de nos experts sur les techniques, plateformes, outils, langages et frameworks associés aux principales technologies mobiles que nous utilisons au quotidien chez BAM : React Native, Flutter et Native.