Deux SDK mobiles pour un éditeur SaaS e-commerce

Le contexte

Un éditeur SaaS de personnalisation e-commerce proposait sa solution sur le web et voulait la porter sur les applications mobiles de ses clients — de grandes enseignes de distribution. Le livrable n’était donc pas une application, mais une brique que d’autres équipes intègrent dans la leur.

L’enjeu

Un SDK n’a pas les mêmes règles qu’une application. Personne ne voit le code, et c’est justement le problème : ce que les développeurs clients voient, c’est la surface d’API, le message d’erreur à 18 h un vendredi, et le temps qu’il leur faut pour comprendre comment brancher la chose.

Trois contraintes en découlaient :

1. L’API publique est un engagement. Une fois qu’une enseigne a intégré le SDK dans son application, chaque changement de signature devient un coût pour elle. Il faut viser juste dès le départ.
2. On ne maîtrise pas l’application hôte. Le SDK doit cohabiter avec des architectures et des versions qu’on ne choisit pas, sans imposer ses propres dépendances.
3. Deux plateformes, une seule cohérence. Un développeur iOS et un développeur Android doivent retrouver les mêmes concepts, même si le langage diffère.

Ce que nous avons fait

• SDK Android, distribué en bibliothèque autonome, avec une gestion explicite des dépendances transitives — le point sur lequel une intégration échoue presque toujours en premier.
• SDK iOS, distribué via Swift Package Manager, avec une API pensée pour ressembler à celle du SDK Android : mêmes concepts, mêmes noms, initialisation symétrique.
• Plusieurs initialiseurs, du plus simple (une clé d’API) au plus complet (URL de serveur, environnement, journalisation). Cas simple immédiat, cas avancé possible.
• Configuration multi-tenant et bascule production / préproduction, pour que les équipes clientes puissent tester sans toucher aux données réelles.
• Applications de démonstration en UIKit côté iOS, et en vues classiques comme en Jetpack Compose côté Android. Un intégrateur trouve un exemple qui ressemble à son propre code, quelle que soit sa génération d’architecture.
• Documentation d’intégration livrée avec chaque SDK.

Le résultat

Deux SDK natifs livrés en parallèle, prêts à être intégrés par les équipes techniques des enseignes clientes de l’éditeur.

Sur ce type de mission, la qualité se mesure à une chose : le nombre de questions que l’intégrateur doit poser avant que ça marche. Tout le travail d’API, de nommage symétrique et d’exemples multiples sert à faire tendre ce nombre vers zéro.