Je ne suis pas développeur et j'ai livré une app mobile avec des agents IA.

Quatre mois passés et une application bilingue anglais-arabe pour le Golfe. Voici ma méthode, les outils que j'utilise, où part le temps, ce que j'ai appris à mes dépens, et ce que l'IA ne fait toujours pas à ma place.

D'où je pars

Je ne suis pas développeur et personne ne m'a appris à coder.

En mai 2026, j'ai lancé une application de budget pensée d'abord pour le Qatar, puis pour le reste du Golfe. Elle aide les expatriés à calculer leur budget. Elle fonctionne en anglais et en arabe. Elle propose un système de progression (niveaux, badges, séries de jours) et compare les frais des transferts d'argent vers le pays d'origine, ce qui concerne beaucoup d'expatriés. Techniquement, c'est une app React Native en TypeScript, avec Expo.

Aujourd'hui, le projet ressemble à ceci :

• • 800 commits depuis le 19 mai 2026
  • 1 000 tests automatisés
  • 46 specs de conception écrites avant le code
  • 2 langues, dont l'arabe de droite à gauche
  • 0 ligne de code écrit à la main, 100% vibe codée .

Mes outils

J'utilise Claude Code qui tourne dans le terminal et qui a accès à tout le projet : fichiers, tests, git, et le téléphone Android branché en USB. Le modèle principal (Opus 5) orchestre le travail. Il lance des sous-agents, chacun avec une mission précise et son propre contexte.

Seul, l'agent est capable mais pas discipliné, c'est là où il faut utiliser des "skills" (compétences en français). Ce sont des procédures écrites qu'on installe et que l'agent suit à la lettre selon le type de tâche. Voilà les pirincipales skills que j'utilise :

• • Superpowers : la colonne vertébrale du processus. Brainstorming obligatoire avant toute fonctionnalité, rédaction d'un plan, développement confié à des sous-agents avec une relecture après chaque tâche, débogage qui cherche la cause avant de corriger.
  • gstack : des rôles de direction business et ingénierie logicielle issue du meilleur incubateur au monde (Y combinator). /office-hours pour challenger une idée, /plan-ceo-review et /plan-eng-review pour relire un plan d'un œil business ou d'un œil technique, /cso pour un audit de sécurité, /design-review pour la qualité visuelle.
  • Matt Pocock : grill-with-docs, qui m'interroge sans relâche sur un plan en le confrontant au vocabulaire du projet, et improve-codebase-architecture pour simplifier l'architecture globale de mon code avant d'ajouter de nouvelles fonctionnalités.
  • ui-ux-pro-max et awesome-design-md : des bases de connaissances en design (palettes, typographies, bonnes pratiques d'interface) que l'agent consulte avant de proposer un écran.
  • Mes propres skills : verify lance l'app sur mon téléphone et vérifie un changement par captures d'écran. persona-simulation fait « vivre » l'app à des utilisateurs types pendant des semaines simulées. autoloop encadre les améliorations autonomes pendant la nuit.

J'ai aussi développé un document de routage pour que l'agent coordinateur indique pour chaque type de tâche, quel skill utiliser. L'agent le lit avant de commencer tout travail:

Ma méthode en quatre temps

Après plusieurs sessions où l'agent a beaucoup produit sans que j'aie rien vu de concret, j'ai imposé une boucle. Elle est écrite noir sur blanc dans le fichier d'instructions que l'agent lit à chaque session :

1. 1. Enquêter: Lire le code, les tests et la config avant de me poser la moindre question.
   2. Proposer: Du HTML pour tout ce qui se voit, un résumé de décision pour le reste.
   3. J'approuve: Rien ne se construit sans mon feu vert.
   4. Construire: Par petites tranches, chacune vérifiée par les tests.

A. Montre moi ce que tu vas développer avant de le coder

Tout ce qui a une surface visible me parvient d'abord sous forme visuelle (page HTML) générée à partir du code de l'app, et non recopiée à la main. Ce que je valide est exactement ce qui sera livré. Pour les autres sujets, j'attends un résumé court, comme on en présente à un dirigeant : les options, une recommandation, et c'est tout.

B. Celui qui relit n'est jamais celui qui a écrit

Un agent écrit, un autre, dans un contexte séparé, relit sans connaître le raisonnement du premier, et un troisième intervient pour livrer. Mon journal de leçons compte plus de dix cas où cette relecture indépendante a trouvé ce que l'auto-relecture avait laissé passer.

C. Une règle importante devient un automatisme

Une consigne écrite finit par être oubliée. Quand une règle doit tenir à chaque fois, je la transforme en hook, un script que l'environnement exécute automatiquement. Par exemple, l'agent ne peut pas terminer son tour si les tests échouent : le script le bloque.

D. Une mémoire qui survit aux sessions

Un agent repart de zéro à chaque session. J'ai donc construit une mémoire sous forme de fichiers qui vivent dans le projet :

• • CLAUDE.md : les instructions de base, lues à chaque démarrage.
  • CONTEXT.md : le vocabulaire métier, pour que tout le monde appelle les choses de la même façon.
  • LEARNINGS.md : chaque surprise, chaque erreur, notée au moment où elle arrive. Plus de mille lignes aujourd'hui.
  • STATE.md : le point de reprise, affiché automatiquement au début de chaque session.
  • DESIGN.md et PERSONAS.md : le guide visuel, et les sept profils d'utilisateurs types qui servent de référence pour toute décision produit.
  • Des ADR : une fiche par décision difficile à défaire, avec le compromis qu'elle implique.

À côté, je tiens un coffre Obsidian où je range les bonnes pratiques qui valent pour tous mes projets, et pas seulement pour celui-ci.

Mon temps de vibe coder est réparti en 4 activités

On imagine que le plus long, c'est d'écrire le code. En réalité, c'est la partie qui m'a pris le moins de temps : les agents l'écrivent en quelques minutes. Mes journées, et une bonne partie de mes nuits, sont parties dans trois activités.

1. Le débogage

Environ un tiers de mon temps de développement : 172 commits de correction pour 329 commits de fonctionnalité, soit environ une correction pour deux nouveautés

2. Le design

Environ 50 heures passées dessus. Les agents produisent vite une interface correcte. Une interface qui donne envie d'ouvrir l'app tous les jours, c'est une autre affaire.

Le parcours de démarrage, ces premiers écrans qui décident si quelqu'un garde l'app, a été repensé quatre fois en cinq jours en juillet, avec une spec à chaque fois (et c'est toujours pas terminé :'( )

Pour tenir la qualité, j'ai fini par écrire un guide de style (DESIGN.md) que les agents n'ont pas le droit de modifier sans mon accord, et une procédure de revue qui passe chaque écran, dans chaque état, en anglais et en arabe : avec ou sans données, en cas d'erreur, en cas de dépassement.

3. Les tests humains, sur le téléphone

C'est la partie qui ne se délègue pas. Près de mille tests automatisés passaient au vert pendant que l'interface arabe affichait des phrases en anglais : les tests ne vérifiaient que la version anglaise. Seul un passage à la main, écran par écran, en arabe, l'a montré.

J'ai essayé de confier ces tests à l'agent en lui donnant le contrôle du téléphone. Les taps envoyés à l'aveugle atterrissaient dans WhatsApp ou tapaient du texte dans le mauvais champ. Au bout de quelques tentatives, je reprenais la main : j'allais plus vite moi-même. Aujourd'hui, l'agent se charge des vérifications simples (ouvrir un écran précis, lire une valeur enregistrée) et moi de tout ce qui demande un œil.

4. Les nuits où l'agent travaille seul

Un soir de juillet, avant d'aller dormir, j'ai écrit à l'agent de continuer toutes les tâches, de reporter ce qui ne bloquait pas, de trancher ce qui bloquait, et de m'expliquer le lendemain chaque décision prise et pourquoi.

Il a enchaîné sept fonctionnalités complètes, chacune avec sa spec, son plan, son développement et sa relecture, soit une quarantaine de commits. La relecture finale de chaque branche a attrapé six bugs avant qu'ils n'arrivent en production, dont une situation de concurrence qui faisait perdre des points d'expérience. Le matin, un rapport m'attendait. Je l'ai lu et j'ai répondu « c'est bon, on continue ».

L'inverse est aussi arrivé (et souvent !): une autre nuit, j'avais laissé le téléphone branché exprès pour que l'agent teste. Il a quand même livré moins que demandé, par excès de prudence : « je ne peux pas vérifier ça cette nuit ». Je lui ai dit clairement qu'il avait désobéi. C'est devenu une règle : soit il exécute entièrement, soit il signale le blocage précis immédiatement. Il ne réduit jamais le périmètre en silence.

Ce que j'ai appris à mes dépens

1. Relire le plan avant d'écrire le code

Pour la brique qui envoie des statistiques anonymes, une relecture indépendante du plan, avant la moindre ligne de code, a trouvé cinq défauts que l'agent auteur n'avait pas vus.

2. Un changement doit atteindre tous les écrans/interactions concernés

J'ai demandé que le nom de l'objectif choisi par l'utilisateur apparaisse sur l'accueil. L'agent l'a fait sur l'accueil, et nulle part ailleurs. Les autres écrans affichaient encore l'ancien libellé. Maintenant, avant tout changement, l'agent doit se poser la question : « où cette information est-elle lue, et où ce changement doit-il aussi apparaître ? » (et il en oublie souvent, d'où l'importance du test manuel)

3. Mesurer les injections de token (surtout en début de session)

Un de mes scripts de démarrage injectait environ 14 000 tokens au début de chaque session, à cause d'une expression régulière mal écrite. Personne ne l'avait remarqué pendant des semaines, parce que rien ne plantait. Depuis, je fais mesurer ce que chaque script injecté au démarrage.

4. Les consignes vieillissent avec les modèles

Une consigne comme « vérifie bien ton travail » aidait les anciens modèles. Sur les plus récents, qui se vérifient déjà seuls, elle provoque de la sur-vérification et coûte des tokens pour rien. Je tiens donc un fichier de consignes par modèle, daté, que je reteste à chaque changement de version.

5. Retirer plutôt qu'ajouter

Ma dernière simulation a fait vivre l'app à mes sept profils d'utilisateurs, avec un agent différent pour critiquer chaque rapport. Chacun des huit rapports contenait au moins une affirmation que le critique a démontée. Les cinq priorités qui en sont sorties étaient toutes des suppressions ou des corrections, sans aucune nouvelle fonctionnalité.

Les limites

Ce qui reste difficile, quatre mois plus tard.

• • La documentation finit par mentir. Récemment, le fichier d'instructions décrivait comme « en cours » une fonctionnalité livrée depuis des jours. Chaque agent qui le lisait partait d'une fausse prémisse. Une mémoire qu'on n'entretient pas devient problématique, et l'entretenir prend du temps, que je n'ai pas toujours.
  • L'agent désobéit parfois à une consigne explicite. Des données personnelles de test ont été enregistrées dans le projet à deux reprises alors que je l'avais interdit. Une interdiction écrite ne suffit pas : ce qui est critique doit être bloqué mécaniquement.
  • Le parallélisme a un coût caché. Plusieurs agents en même temps, chacun dans sa copie du projet, ça va vite. Mais une copie est un jour partie d'une version en retard de dix commits, et l'agent en a conclu qu'une fonctionnalité « n'avait jamais été construite ».
  • Le monde physique résiste. Le téléphone, la compilation, le cache : tout ce qui sort de l'écran de l'ordinateur reste lent et fragile à confier à l'IA.
  • On devient vite accro. Voir une équipe livrer pendant qu'on dort, c'est excitant, et ça ne laisse plus tranquille. Je me suis surpris à me lever au milieu de la nuit pour aller voir où en étaient les agents, lire le dernier commit, relancer une tâche bloquée. L'historique git en garde la trace : près de 18 % des commits datent d'entre minuit et 3 heures du matin. Une partie vient des nuits où l'agent travaillait seul, mais même ces nuits-là, je me relevais pour surveiller. Fixer des heures d'arrêt fait partie de la méthode, même si je ne les respecte pas encore assez.
  • Ça coûte. L'abonnement et les tokens, mais surtout l'attention : il faut surveiller ce que les agents livrent.
  • Beaucoup de décisions restent humaines. Ce qu'on construit et ce qu'on refuse de construire. Ce qu'on promet à l'utilisateur sur ses données. Le prix. Le marché. L'IA peut argumenter, et je lui demande de me contredire franchement, mais c'est moi qui tranche et qui en porte la responsabilité.

Conclusion

1. 1. Dirigez, ne codez pas. Votre valeur tient dans le choix de ce qu'on construit, et dans le refus de ce qui ne sert à rien.
   2. Exigez de voir avant qu'on construise. Une maquette HTML vaut mieux qu'un long compte rendu.
   3. Ne laissez jamais un agent relire son propre travail. Faites relire par un autre agent, dans un contexte séparé, à chaque fois.
   4. Écrivez vos erreurs le jour même. Un fichier de leçons que l'agent relit lui évite de refaire les mêmes.
   5. Transformez chaque règle vitale en automatisme. Une consigne écrite finit par être oubliée, un hook s'exécute à chaque session.

Je n'étais pas développeur il y a quatre mois, et je ne le suis toujours pas. Je suis devenu quelqu'un qui sait diriger des agents qui développent. Aujourd'hui, c'est une compétence à part entière, et c'est celle que j'ai apprise grâce aux équipes de IA LA SOLUTION.

IA La Solution

Chez IA La Solution, chaque recommandation s'appuie sur des implémentations réelles. Nous vous aidons à vous former sur le vibe coding et à développer vos propres applications.

Écrivez-nous à les.consultants.ia@ialasolution.com ou réservez 30 minutes : calendly.com/les-consultants-ia/30min.