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 : 

• D'une part, les choix ne font pas nécessairement consensus au sein de l’équipe, car ils sont souvent portés par une même personne
• D'autre part, même si le choix est consensuel, ce n'est pas forcément le meilleur
• Enfin, le choix n'étant pas documenté, les équipes qui reprendront le code ne le comprendront pas

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é :

• Cela se traduit par l’oublie de cas limites, qui va conduire à des bugs et/ou à des fonctionnalités incomplètes
• Les macro estimations qui en résultent sont peu fiables, car il y a beaucoup de retours d'un sprint à l'autre

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 : 

• Se mettre d'accord sur le scope exact de la fonctionnalité et d’améliorer la compréhension commune
• Faciliter la levée d'alerte en mettant en avant des zones d’ombre
• Visualiser la complexité fonctionnelle et technique
• Permettre une meilleure QA et faciliter le débogage

Les bénéfices sont flagrants :

• On constate moins de bugs
• Le lead time nécessaire pour sortir une fonctionnalité diminue
• On remarque un meilleur alignement entre les équipes
• Une meilleure fiabilité des estimations

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 ligne de code a introduit ce problème ? 
• Qui ? Dans quelles circonstances réelles ?
• Quelles sont les causes profondes qui ont amené ce problème ? (ex: un manque de standard, de connaissances ?)
• Pourquoi on n'a pas détecté ce défaut plus tôt ? (mur de qualité)
• Qu'est-ce qui aurait pu empêcher d'introduire ce problème ?

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 :

• Appium a rencontré des problèmes de compatibilité avec React Native, notamment pour récupérer un élément par test-id (crucial). Ces problèmes ont été corrigés par une mise à jour de React Native.
• Sa documentation paraît obscure et labyrinthique, notamment parce qu'Appium supporte de nombreux langages et plateformes (mobile, web, desktop...)

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 :

• Segmenter la code base en petits domaines (voir micro features architecture)
• Gérer les règles métiers au sein de ces domaines

Robert C. Martin, Jeffrey Palermo et d'autres architectes référents de l'onion architecture et la clean architecture apportent plusieurs recommandations :

• Séparer les règles métiers des technologies utilisées, qui ne changent pas dans le même contexte. Tandis que le code lié aux règles métiers doit être compréhensible par quelqu'un du métier et ne changera qu'en cas de modifications des besoins fonctionnels, le code lié aux technologies est plus instable, les frameworks évoluant régulièrement.
• Utiliser l'injection de dépendances (ex: via koin ou resolver) pour que les règles métiers ne dépendent pas des technologies. Cela permet d'améliorer la testabilité et de rendre les changements d'infrastructure plus rapides.

Nous avons appliqué ces architectures sur le terrain pour nos projets iOS et Android, ce qui nous a permis d'émettre plusieurs constats : 

• Un code métier plus clair et compréhensible
• Une simplification pour tester unitairement le code métier
• Des fichiers plus courts
• La possibilité de modifier une fonctionnalité sans introduire de régression
• Plus de facilité à repousser les choix de frameworks / librairies à utiliser. Cela permet de prototyper une application avec des choix d'infrastructures moins complexes (ex: persister de la donnée dans un fichier .txt plutôt que monter une base de données mySQL).

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 :

• Qui : qui pourrait être l’agent de menace ?
• Comment : quel serait son vecteur d'attaque (accès direct à l'appareil ou accessible en ligne) et quelles préconditions sont nécessaires (malware installé, hameçonnage…) ?
• Quel impact : est-ce que cela affecte la confidentialité des données (accès en lecture à des données non autorisées), l'intégrité des données (accès en écriture ou suppression à des données non autorisées) ou la disponibilité (empêcher l'accès à d'autres) ?

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 :

• Ces questionnements permettent aux équipes d'avoir un avis critique sur leur application, sans demander trop de connaissances au préalable. De plus, le classement des failles de sécurité les plus fréquentes OWASP aide les équipes à éviter qu'une faille ne soit déployée en production.
• Les résultats permettent également d'avoir un système de notation stable et uniforme. Ce système est également utilisé pour les nombreuses failles de sécurité qui peuvent être présentes dans les dépendances téléchargées. Ceci permet donc d’avoir une notation homogène entre les failles internes et externes au projet. Ce système de notation donne des outils aux équipes pour prioriser ou arbitrer une décision technique. Nous vous conseillons d'utiliser CVSS pour évaluer le niveau de sécurité de vos applications.

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 :

• La situation n'est pas claire : en tant que développeur, il est alors impossible de savoir ce qu'il s'est passé au moment du problème
• Il n'y a pas non plus d'éléments de contexte du problème, comme les logs applicatifs ou les requêtes envoyées. 
• D'un autre côté, les services de monitoring ne permettent pas de détecter toutes les mauvaises expériences utilisateur

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éparer le développement en amont et anticiper tout blocage
• éviter l’effet tunnel grâce à une meilleure visibilité sur le projet
• identifier rapidement une difficulté pour réagir et solliciter son équipe en cas de besoin
• faciliter le découpage en commits du code et simplifier la relecture

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 :

• Implémentation d’algorithmes simples, ex. : division, boucle, itération, tri
• Rendre les équipes plus efficaces dans un langage que l’on maîtrise peu (ex: configuration Fastlane en Ruby pour un développeur TypeScript)
• Recommandations des interfaces ou modèles typiques (ex: Country, Person)
• Proposition de test cases standard dans les tests unitaires

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 :

• Le risque légal est lié à une utilisation potentielle du code copié d'un projet, avec une licence fermée. Cela entraînerait donc une entrave à la propriété intellectuelle. Les avis divergent, mais la situation n'est pas vraiment claire tant qu'il n'y a pas une jurisprudence à ce sujet aux US.
  
  
• L'autre risque est plus lié au travail des développeurs avec une tendance à accepter une recommandation sans vraiment vérifier si le code est correct (surtout chez des développeurs juniors) et un sentiment de perte de sentiment d'ownership du code écrit.

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.