Deux ans de lead sur Odisei Play : une seule codebase sur iOS, Android et web, une release toutes les deux semaines, à deux engineers avec des agents IA. Ce rôle dans votre équipe, ou le setup du repo qui rend ce rythme possible.
Comment on a fait passer une designeuse de Figma seul à pusher des composants de prod dans une codebase React Native.
Deux devs. Une designeuse qui sortait de vrais bons designs dans Figma.
La boucle avait l'air saine. Elle designait, on validait, tout le monde tombait d'accord sur la nouvelle UI, que ce soit pour un vieux bout de l'app ou pour la feature à venir. Puis le design restait sur l'étagère pendant des semaines, le temps qu'on priorise autre chose.
Quand je finissais par attaquer l'implémentation, la vérité tombait d'un coup. Des dégradés radiaux, des effets SVG que React Native n'expose pas facilement, certains partis pris visuels n'allaient jamais survivre au contact du framework. Pas parce que les designs étaient mauvais. Parce que le framework, le temps que j'avais, ou les deux, ne pouvaient pas les tenir.
Donc on shippait une version au rabais. Pas par flemme. Par collision entre ce que React Native sait faire et les heures que j'avais pour le faire.
Il y avait aussi la taxe sur les assets. Figma est un bon point de départ, mais il fallait quand même exporter chaque asset visuel, l'importer, le wirer à la main dans la codebase. Et des choix techniques se prenaient sans que personne ne voie qu'ils étaient coûteux, parce qu'on ne peut pas demander à une designeuse de connaître les limites d'un framework dans lequel elle n'écrit pas de code.
Résultat : un écart permanent entre le design qu'on avait validé et le design qui partait en prod. Un problème produit déguisé en problème de process.
On ne pouvait pas lui apprendre React Native, et on aurait eu tort d'essayer. Le vrai fix, c'était de faire de la codebase un endroit où elle pouvait travailler directement.
J'ai préparé le repo pour les agents. C'est toute la base, et je veux le dire clairement. Elle n'est pas devenue développeuse du jour au lendemain. Elle a récupéré une codebase rendue sûre et lisible pour un agent, et Claude Code lui a donné le moyen d'y travailler.
Elle s'est mise à vibe-coder ses propres composants dans un dossier packages/ui. Elle les passait en review. Et ces reviews faisaient double emploi. Chacune repérait des problèmes, et rendait au passage son setup Claude Code un peu meilleur, un peu plus contraint, un peu plus capable d'écrire du code correct du premier coup.
Elle voyait tout dans Storybook. Storybook s'est révélé la pièce idéale pour elle. Un environnement isolé où un composant s'affiche ou ne s'affiche pas, sans contexte d'app à démêler.
Si ta designeuse est coincée dans Figma et que le design se dégrade à chaque fois sur le chemin de la prod, ça se répare. Voici le travail.
On a documenté comment un composant doit être construit, et une seule règle a fait le gros du boulot.
Si ça s'affiche correctement dans son Storybook, ça marche dans l'app.
Web, iOS, Android. Landscape et portrait. Les skills et la CI qu'on a mis en place l'appliquaient, donc elle n'avait plus besoin de savoir ce que le framework pouvait faire ou pas. La question « est-ce que ça va marcher dans l'app », celle qui dégradait chaque design en silence, c'est le système qui y répondait, plus la disponibilité d'un dev.
Rien que ça a transformé l'écart entre le design et la prod, d'un pari en une garantie.
On a ajouté un fichier recipe.md, créé à chaque fois que la designeuse travaillait sur un composant. À quoi sert ce composant, comment il est censé être utilisé, comment il se wire dans la vraie app.
Ça a l'air de rien. Ça a fait boule de neige. Chaque composant arrivait avec sa propre explication, donc le wiring devenait plus simple à chaque fois. On a fini par sortir les assets, les fonts et quelques utils dans un package qui marchait à la fois dans Storybook et dans l'app.
Le flow tournait mieux à mesure qu'on s'en servait, et c'est le signe qu'il devenait un système, au lieu d'une suite de sauvetages au cas par cas.
C'est tout l'intérêt des workflows IA dans une codebase, et je veux finir là-dessus parce que c'est la partie que les gens ratent.
Ce n'est jamais fini. Les nouveaux modèles débloquent des choses qui n'existaient pas avant. Des règles qu'il fallait imposer en permanence peuvent sortir du système. Ce qui était impossible au trimestre dernier devient routinier. Tu adaptes, tu corriges là où ça casse, et ça casse moins à chaque fois.
Le design qu'elle a validé, c'est maintenant le design qu'elle ship. Ce n'est pas un process plus agréable. C'est un autre produit.
Deux devs, une release toutes les deux semaines. C'était la codebase d'Odisei Play. Parlons de ton app.