Vous avez un projet d'application devant vous, et 2 discours contradictoires. Le premier dit que l'IA écrit le code à votre place, et qu'un projet de 6 mois se fait maintenant en 6 jours. Le second dit que ça marche pour une démo de 3 écrans, et que tout s'écroule sur un projet réel. Les 2 se lisent partout, et aucun ne vous donne de chiffre sur un projet qui ressemble au vôtre.
Une précision s'impose avant de commencer. Cet article ne parle pas d'une petite application de 3 ou 4 écrans montée en un week-end. Il parle d'une application de santé de 85 écrans, avec un parcours patient réglementé, un serveur existant et des règles métier que personne n'a le droit d'approximer. C'est le cas où la question se pose vraiment.
Le projet a été exploré au printemps 2026, le temps d'écrire la spécification et de monter l'outillage, puis a officiellement commencé en juin et s'est terminé fin août. Voici le bilan, poste par poste : ce que l'IA a changé, ce qu'elle n'a pas changé, là où elle a fait perdre du temps, et la méthode qui a permis de tenir l'échéance.
Le projet : refaire sur Android une application de santé de 85 écrans
Le contexte est celui de DI&Care, une medtech française qui développe Noxxea, une application d'accompagnement pour les patients. Elle existait sur iPhone. Sa version iOS avait demandé 1 an et demi de travail, entre des spécifications longues à écrire et le développement. Puis 6 mois de recette, c'est-à-dire de tests à la main de toute l'application avant sa mise en service. Un délai courant pour une première application de cette taille dans la santé, entre les règles à trancher et les validations à obtenir.
Le problème était commercial, celui de toute application présente sur une seule plateforme. Sans version Android, l'application ne touche qu'une partie du marché : en France, 2 téléphones sur 3 tournent sous Android, et l'application ne les touchait pas. La rentrée de septembre était le bon moment pour commencer à monétiser, et il fallait les 2 plateformes pour y arriver. Un projet Android au rythme du projet iOS aurait rendu l'échéance impossible.
La proposition faite à l'équipe : assurer le développement Android en 1 personne, en 3 mois, sans être expert Android. Ce qui rendait le pari tenable n'était pas la maîtrise de la plateforme. C'était 2 autres choses, le serveur étant la partie de l'application qui tourne à distance et détient les données :
- Une connaissance complète du serveur sur lequel l'application se branche.
- Une connaissance complète des règles métier.
Chaque fois que l'IA poserait une question de choix technique ou fonctionnel, la réponse existerait déjà.
Un choix technique a été posé avant de commencer : du code natif, c'est-à-dire écrit dans le langage propre à Android, Kotlin, avec Jetpack Compose, la bibliothèque d'interface de Google. L'autre option était un outil multiplateforme comme Flutter ou React Native, qui produit les 2 applications à partir d'un seul code. La raison n'est pas une préférence : certaines mesures que l'application relève sur le téléphone sont plus simples et plus sûres à faire en natif, sans couche intermédiaire à maintenir. Et Compose ressemble de près à SwiftUI, la bibliothèque d'interface de la version iOS : les écrans s'écrivent de la même façon, ce qui rend le portage lisible pour l'IA comme pour le relecteur.
Le calendrier a aussi compté. Un agent de code est un assistant d'IA qui écrit et teste le code seul, à partir d'une consigne. Juin 2026, c'est le moment où, sur les essais menés pour ce projet, Codex d'OpenAI et Claude d'Anthropic sont devenus assez fiables pour tenir un objectif entier. Ils ne prenaient plus une consigne à la fois, et ils savaient se répartir une tâche entre plusieurs agents. Le projet a démarré à ce moment-là.
Ce qui a changé : 3 mois au lieu de 2 ans pour la même application
Voici les 3 mois, avec ce qui existait à la fin de chacun et ce que l'IA y a fait :
Mois 1 : un premier jet complet de l'application
85 écrans posés- Ce qui existe
- Tous les écrans existent et s'enchaînent. Le parcours patient se déroule de bout en bout, branché sur le vrai serveur. Beaucoup de détails sont faux, et c'est normal.
- Ce que l'IA a fait
- L'IA a produit les écrans, les tickets de spécification dans l'outil de suivi, la documentation et les tests unitaires, c'est-à-dire les tests automatiques de chaque brique de code. Aucun de ces 4 postes n'a été tapé à la main : l'IA les produit, à partir des règles données par l'humain.
Mois 2 : 90 % du développement, validé en recette
Reste les cas limites- Ce qui existe
- Les décalages avec la version iOS sont corrigés un par un. Il reste des bugs, des cas limites, des écrans qui se comportent mal sur certains téléphones.
- Ce que l'IA a fait
- L'IA corrige ses propres erreurs vite, quand la correction est petite. Mais c'est aussi le mois où une dizaine de sessions ont été jetées entières, parce que le code produit n'était plus relisible.
Mois 3 : la recette, parcours par parcours
Prête pour la recette finale- Ce qui existe
- Toute l'application est rejouée à la main, sur plusieurs téléphones, avec les règles métier d'une appli de santé. C'est le mois qui ressemble le plus à un projet d'avant.
- Ce que l'IA a fait
- L'IA recette une partie la nuit, avec des captures d'écran, mais un humain reste plus rapide sur un téléphone. Le temps de recette n'a presque pas bougé.
Pour donner une idée de ce que « 85 écrans » veut dire, voici 4 écrans de l'application Android telle qu'elle tourne aujourd'hui sur un téléphone :
Le temps a été gagné sur 4 postes, ceux où l'IA a tout changé :
- Les écrans
- 85 écrans à reproduire depuis la version iOS, avec leur logique, leurs états vides, leurs messages d'erreur. Sur un projet classique, c'est le poste le plus long. Ici, c'est celui qui est allé le plus vite : un écran décrit correctement sort en premier jet en quelques minutes, et chaque correction prend quelques minutes. Le temps passe dans la description et la relecture, plus dans le code.
- Les tickets et les spécifications
- Chaque parcours a été découpé en tickets, avec la règle métier, les cas limites et les critères de validation écrits dedans. Sur un projet d'avant, ce travail prend des semaines et se fait à moitié. Ici, il se fait en amont de chaque parcours, et l'IA s'en sert directement pour coder.
- La documentation
- L'application est documentée au fur et à mesure : l'architecture, les choix, la façon de la lancer et de la tester. Personne ne l'aurait écrite à la main sous une échéance de 3 mois. Elle existe parce qu'elle ne coûte plus rien.
- Les tests unitaires
- Les tests automatiques de chaque brique de code sont écrits en même temps que la brique. C'est le poste que la plupart des projets sacrifient en premier quand le délai se resserre. Il n'a pas été sacrifié.
Sur la publication, à chaque fois qu'un lot de code validé rejoint la version commune, une version prête à installer part automatiquement chez les testeurs internes, via le Play Store. La sortie publique dépend maintenant du calendrier commercial et de la validation du Play Store, pas de la technique : pour la première fois sur ce produit, elle n'est plus le goulot.
Sur ces 4 postes, 3 ne sont pas du code. Les tickets, la documentation et les tests sont ce qu'un projet sous pression abandonne en premier. C'est aussi ce qui se paie le plus cher 2 ans plus tard, le jour où quelqu'un reprend l'application. Ici, ils ont été faits parce qu'ils ne coûtaient plus rien.
Et le projet a livré plus que prévu. Le cahier des charges disait : reproduire l'application iOS sur Android. À la fin du deuxième mois, il restait du temps. Il a servi à faire évoluer le parcours de l'application côté Android, pendant que l'équipe iOS faisait de même de son côté. Sur un projet d'avant, cette évolution aurait été un deuxième devis, l'année suivante.
Ce qui n'a pas changé : la recette, et le métier à connaître
On pourrait croire que tout a accéléré. Ce n'est pas ce qui s'est passé. Le troisième mois ressemblait à un troisième mois d'avant : l'application entière rejouée à la main, sur plusieurs téléphones, écran par écran, règle par règle. L'IA peut aider à recetter. Elle a été outillée pour installer l'application, naviguer dedans et prendre des captures, et elle l'a fait une partie des nuits. Mais elle reste lente sur un téléphone, et la recette d'une application de santé ne s'apprend pas en une nuit. Un humain qui connaît le métier va beaucoup plus vite.
Pour préciser ce que vous devez valider, le décryptage sur les devis de correction des bugs montre comment les critères d'acceptation aident à distinguer un défaut du fonctionnement commandé et un besoin supplémentaire.
Pour votre projet aussi, le second poste qui n'a pas bougé explique tout le reste, même s'il est moins visible. Ce projet est allé vite parce que le cahier des charges était complet avant la première ligne de code. Toutes les règles avaient déjà été tranchées sur la version iOS. Elles étaient écrites, et surtout elles étaient dans la tête de la personne qui répondait à l'IA. Une question de comportement, une réponse en 10 secondes, et l'IA repartait.
Prenez le même projet avec un cahier des charges à écrire en chemin. Chaque question de l'IA devient un mail, une réunion, un arbitrage entre 2 personnes qui ne sont pas d'accord. Le développement attend. Au lieu de passer de 2 ans à 3 mois, vous passez peut-être de 2 ans à 1 an, et l'année qui reste est faite de réunions, pas de code. L'IA a divisé le coût d'écrire le code. Elle n'a rien changé au coût de savoir quoi écrire, et c'est ce coût-là qui fixe maintenant la durée d'un projet.
Là où l'IA a fait perdre du temps sur le projet
Les démonstrations n'en parlent pas : l'IA a aussi coûté du temps, à 3 endroits :
- Les écarts d'interprétation avec la version iOS
- L'IA reproduit un écran à partir d'une description et de captures. Elle interprète. Un espacement, un ordre de champs, un comportement au clavier : chaque écart se voit tard, à la recette, et se corrige un par un. C'est du temps perdu qu'une maquette plus stricte au départ aurait évité en partie.
- Les sessions jetées
- Une session est une séance de travail avec l'IA, sur une tâche. Plusieurs fois, dans une même session, l'IA a touché trop de fichiers d'un coup. Le résultat marchait peut-être, mais il était impossible à relire : trop de changements, dans trop d'endroits, pour valider l'architecture et la logique. Une bonne dizaine de sessions ont été annulées entièrement et refaites en plus petit. Le seuil pratique : au-delà de 10 fichiers touchés dans une session, la relecture n'est plus possible, et le résultat est refusé. Mettre en production un code de santé sans l'avoir relu n'est pas une option.
- La recette
- Tester tout le fonctionnel à la main, sur plusieurs téléphones, a pris presque autant de temps qu'avant. L'IA sait le faire, et elle l'a fait une partie des nuits. Mais elle est lente sur un téléphone, et un humain qui connaît le métier voit d'un coup d'œil ce qu'elle met de longues secondes à vérifier.
Les sessions jetées méritent 1 mot de plus, parce qu'elles disent quelque chose sur la façon de travailler avec l'IA. Le code produit marchait peut-être. Personne ne le saura, parce qu'un code que personne ne peut relire ne va pas en production dans une application de santé. Le choix de tout annuler et de recommencer plus petit a coûté des heures. À la vitesse où le code se refait, ces heures n'ont pas pesé sur l'échéance. Elles ont surtout servi à apprendre où mettre la limite.
Votre relecture devient le poste rare quand la génération de code ne coûte presque rien. Jeter n'est plus une perte, et tout ce qui rend la relecture impossible se paie tout de suite. C'est aussi ce qui distingue ce projet d'un outil interne construit avec l'IA sans méthode : la même vitesse, mais avec quelqu'un qui refuse ce qu'il ne peut pas relire.
La méthode pour développer une application avec l'IA : par parcours, pas par brique
Découpez votre application par pan fonctionnel, pas par couches techniques. L'habitude est de construire d'abord la base de données, puis la connexion au serveur, puis les écrans. Ce projet a été attaqué de l'autre façon. Un parcours entier est pris de bout en bout, du cahier des charges à la recette, avant de passer au suivant.
La méthode elle-même n'a pas été inventée pour l'occasion. Elle vient des agent-skills d'Addy Osmani, ingénieur chez Google et auteur chez O'Reilly, qui a publié librement les fiches de méthode qu'un ingénieur expérimenté applique sans y penser, écrites pour être lues par une IA. Une fiche par étape, une commande par fiche, et une règle qui résume tout : la spécification avant le code, le test comme preuve, une tranche à la fois.
Pourquoi celles-là plutôt que des fiches maison ? Parce qu'il les a sorties en février 2026, et qu'il est reconnu dans le métier bien avant l'IA. Le dépôt compte plus de 90 000 étoiles sur GitHub, le signe que des milliers de développeurs s'en servent. Le principe vaut pour tout l'outillage autour de l'IA, décrit à la section suivante. Prendre ce qui existe chez les meilleurs, faire de la veille pour savoir que ça existe, et garder son énergie pour ce qui n'existe pas, plutôt que d'avoir la prétention de tout refaire.
- 1. Définir /spec : la spécification avant le code.
- 2. Planifier /plan : des tâches petites et isolées.
- 3. Construire /build : une tranche à la fois.
- 4. Vérifier /test : le test est la preuve.
- 5. Relire /review : refuser ce qui ne se relit pas.
- 6. Livrer /ship : petit et souvent.
Sur le projet, ces 6 étapes se rejouent pour chaque parcours de l'application. Concrètement, dans cet ordre :
- 1
Prendre 1 pan fonctionnel de l'application, c'est-à-dire un parcours complet que vous pouvez recetter d'un bloc : l'inscription, une séance, le suivi. Pas une brique technique comme « la base de données » ou « la connexion au serveur ».
- 2
Écrire les spécifications de ce parcours : les règles métier, les cas limites, ce qui doit se passer quand ça rate. C'est la matière que l'IA ne peut pas inventer, et c'est ce qui décide de la vitesse de tout le reste.
- 3
Découper en tickets dans l'outil de suivi, un ticket par écran ou par règle, avec les critères de validation dedans. L'IA lit le ticket et code à partir de lui.
- 4
Faire écrire un plan d'implémentation avant la première ligne de code, et le relire. Un plan de 20 lignes se corrige en 2 minutes. Le code qui en sort, non.
- 5
Laisser coder, en petites unités relisibles. Dès que la session dépasse 10 fichiers touchés, arrêter, jeter, et repartir plus petit.
- 6
Rassembler toutes les fonctionnalités du parcours dans 1 branche de travail, c'est-à-dire 1 version de l'application à part, mise de côté pour ce parcours. Installer l'application sur les téléphones, et recetter le parcours entier d'un coup, à la main.
- 7
Corriger, refaire un tour, puis passer au parcours suivant. L'application grandit parcours par parcours, et chaque parcours livré est déjà recetté.
L'étape 6 heurte une habitude de développeur. Rassembler toutes les fonctionnalités d'un parcours dans 1 version à part, puis tout recetter d'un coup, va contre l'usage : la règle du métier est de tester chaque fonctionnalité séparément, au fil de l'eau. La règle est bonne pour une application en production, avec des utilisateurs. Ici, l'application n'était pas en production et n'avait aucun utilisateur. Recetter un parcours entier, sur un téléphone, avec un vrai patient en tête, était bien plus efficace que recetter 30 fonctionnalités isolées.
Une raison très concrète s'ajoute. Une application mobile se teste sur un vrai téléphone, et une application Android sur plusieurs téléphones. Chaque test veut dire reconstruire l'application, transférer le fichier d'installation, l'installer, la lancer. Ce temps de construction n'est pas négligeable, et il se multiplie par le nombre de fonctionnalités testées une par une. Le regrouper par parcours l'a divisé d'autant.
Le harness : ce que l'IA lit avant d'écrire une ligne, et pourquoi
Le mot circule de plus en plus. Le harness, c'est tout ce qui entoure l'IA pour qu'elle travaille comme un membre de l'équipe et pas comme un stagiaire brillant qu'on n'a pas briefé. Ça couvre ce qu'elle lit avant de commencer, ce qui l'encadre, ce qu'on lui met dans les mains, et ce qui la vérifie sans elle. Sur ce projet, il a pris plus de temps à construire que le premier parcours. C'est lui qui a fait les 2 mois suivants.
Les noms de fichiers sont ceux du projet, les pièces valent pour n'importe lequel. Chacune existe parce que quelque chose avait mal tourné avant. Les 10 pièces, dans l'ordre où l'IA les rencontre :
Ce qu'elle lit
Avant la première ligne : consignes, spécification, plan.
Le fichier de consignes
CLAUDE.md - Ce que c'est
- Le premier fichier que l'IA lit. Il fixe l'ordre des sources de vérité, ici le code iOS avant les règles écrites, et 3 listes : ce qu'elle fait toujours, ce qu'elle demande avant, ce qu'elle ne fait jamais.
- Pourquoi
- Un jour, faute de trouver l'écran iOS correspondant, l'IA en a inventé un. Le fichier porte depuis la règle « ne jamais inventer un écran qui n'existe pas », avec l'exemple du raté. Elle n'a plus été enfreinte sur le reste du projet.
La spécification technique
SPEC.md - Ce que c'est
- Les briques techniques retenues avec la raison de chaque choix, la façon dont le code est organisé, et des critères de succès mesurables : métriques identiques à l'iOS sur 100 jeux de données avec tolérance 0, aucune donnée personnelle dans les journaux.
- Pourquoi
- L'IA ne peut pas viser ce qui n'est pas écrit, et un critère qu'on ne peut pas mesurer n'en est pas un.
Le plan de tâches
PLAN.md - Ce que c'est
- Le découpage en jalons, avec pour chaque tâche ce qu'il faut lire, ce qu'il faut toucher, et la définition de « fini ». Un point de contrôle humain ferme chaque jalon.
- Pourquoi
- Après 3 écrans repris en plusieurs passes, le plan a été gelé jusqu'à ce que l'outillage permette de livrer un écran complet du premier coup. Chaque tâche liste depuis les valeurs exactes de l'écran iOS à reproduire.
Ce qui l'encadre
Les décisions écrites, les écarts tracés, le formatage imposé.
Les notes de décision
docs/ADR/ - Ce que c'est
- Une page par décision d'architecture : le contexte, les options, celle retenue et pourquoi.
- Pourquoi
- Une décision non écrite, l'IA la reprend à zéro à chaque session, et tranche différemment. Écrite, elle la respecte, et un humain peut la contester.
L'inventaire des écarts
docs/IOS_DRIFTS.md - Ce que c'est
- Chaque écart entre Android et iOS est marqué dans le code et inscrit dans ce fichier avec sa raison. Il est subi quand le code iOS et la règle écrite se contredisent, ou choisi quand Android permet de faire mieux, par exemple chiffrer ce qui est stocké sur le téléphone.
- Pourquoi
- Un écart non tracé devient une divergence entre 2 applications sur le même serveur, et ça se découvre par un patient. Le fichier est adressé à l'équipe iOS.
Le hook de formatage
.claude/hooks/ - Ce que c'est
- Un hook est un script qui se déclenche tout seul sur un événement. Celui-ci reformate chaque fichier que l'IA écrit, selon les règles du projet.
- Pourquoi
- Le formatage est le premier motif de refus en relecture, et le plus bête. Automatisé, la relecture ne voit plus que la logique.
Ce qui lui donne des mains
Un patient de test, un simulateur iOS, un téléphone.
Les connecteurs qui donnent des mains à l'IA
.mcp.json - Ce que c'est
- Un connecteur est un outil que l'IA appelle elle-même. Ici, 2 : l'un crée un patient de test avec sa prescription, l'autre pilote le simulateur iPhone pour capturer l'écran de référence.
- Pourquoi
- Sans eux, chaque test commençait par demander un compte à un humain, et l'IA reproduisait un écran de mémoire. Avec, elle crée son patient, joue le parcours et compare ses écrans à l'iOS, seule.
Les scripts de boucle rapide
scripts/ - Ce que c'est
- Un script reconstruit et installe l'application sur le téléphone, un autre lit les journaux, c'est-à-dire ce que l'application écrit en tournant, un autre vérifie la réponse réelle du serveur avant d'écrire le code qui la lira.
- Pourquoi
- La documentation des échanges avec le serveur mentait parfois. Vérifier ce que le serveur envoie vraiment a évité des écrans qui plantent sur un champ absent.
Ce qui vérifie sans elle
La chaîne automatique et la trace dans les tickets.
La chaîne d'intégration continue
.github/workflows/ - Ce que c'est
- Une chaîne d'intégration continue est une série de contrôles qui se lancent seuls à chaque envoi de code : ici la mise en forme, la détection d'erreurs courantes, les tests, et la fabrication de l'application installable. Quand le code est validé, une version part chez les testeurs internes via le Play Store.
- Pourquoi
- C'est la pièce à monter le jour 1. Une fois en place, plus personne ne fabrique ni ne signe une version à la main, les téléphones de test la récupèrent depuis le Play Store, et la limite devient surtout le quota de minutes de calcul.
La boucle de tickets
Linear - Ce que c'est
- Un ticket décrit une tâche et ce qui doit être vrai à la fin. Le ticket existe avant le code, chaque lot de code porte son numéro, le lien vers la relecture est ajouté en commentaire, et le ticket se ferme au passage en production.
- Pourquoi
- Une session d'IA n'a pas de mémoire. Ce qui n'est pas dans le ticket n'existe pas pour la suivante ; avec, un nouvel agent reprend le projet sans relire aucune conversation.
Aucune de ces 10 pièces n'est un outil de génération de code. Les agents changeront de nom dans 6 mois. Le harness, lui, se reconstruit vite d'un projet à l'autre, parce que la liste des pièces reste la même. C'est là que se loge l'expertise : savoir quelle règle écrire, parce qu'on a vu ce qui arrive sans elle.
Lisez le décryptage sur le harness engineering pour savoir quand corriger le harness plutôt que changer de modèle, et comment vérifier celui de votre équipe.
Ce qu'on referait autrement, et ce qui vaut pour votre projet
Sur votre projet, appliquez la seule chose qui changerait sur un prochain : industrialiser la chaîne d'intégration continue dès le premier jour, sur iOS comme sur Android, avant tout le reste. Cette chaîne se monte en quelques jours, et chaque heure qu'elle fait gagner se retrouve des dizaines de fois sur 3 mois, parce que l'IA livre plusieurs fois par jour. Elle a été montée tôt sur ce projet. Elle aurait dû être montée en premier.
Pour votre projet, ce que celui-ci apprend tient en 3 conditions. Vous irez beaucoup plus vite avec l'IA si vous réunissez les 3 :
- Un focus : 1 personne, 1 application, 3 mois, sans autre chantier en parallèle.
- Une méthode : par parcours, avec des spécifications avant le code et une relecture qui refuse ce qu'elle ne peut pas lire.
- Une connaissance concrète du métier et des règles, chez la personne qui répond à l'IA, pour que chaque question trouve sa réponse en 10 secondes.
Si vos règles métier ne sont pas tranchées, commencez par là, pas par l'outil. La troisième condition est celle qui manque le plus souvent, et c'est elle qui fait le délai. Si elles le sont mais que personne chez vous ne sait les traduire en choix techniques, c'est ce que fait une direction technique, et c'est la partie du projet que l'IA n'a pas remplacée.
Auteur de l'article
Fabien Bousquet, CTO externalisé.
Pas une équipe, pas un sous-traitant. C'est moi qui vous écris, qui cadre, qui build, qui livre.
En savoir plus sur mon parcours →Questions fréquentes
Combien de temps faut-il pour développer une application mobile avec l'IA ?
Sur le projet raconté ici, une application de santé de 85 écrans, 3 mois : 1 mois pour un premier jet complet, 1 mois pour atteindre 90 % du développement, validé en recette, 1 mois de recette. La version iOS équivalente avait demandé 1 an et demi de spécifications et de développement, puis 6 mois de recette. Le gain vient d'un cahier des charges déjà tranché et d'une méthode, pas de l'outil seul.
L'IA peut-elle développer une application de santé réglementée ?
Elle peut en écrire le code, à condition que quelqu'un qui connaît les règles métier et les contraintes de santé relise chaque changement avant qu'il parte en production. Sur ce projet, une dizaine de sessions ont été jetées parce que le code n'était plus relisible. Ce que la réglementation exige de l'application ne change pas parce que c'est l'IA qui l'écrit. Ce que le HDS couvre et ne couvre pas est détaillé dans un autre décryptage.
Faut-il être expert Android pour livrer une application Android avec l'IA ?
Non, et ce projet a été livré sans l'être. Ce qui compte est ailleurs : connaître le serveur sur lequel l'application se branche, connaître toutes les règles métier, et pouvoir répondre en 10 secondes à chaque question de choix que l'IA pose. Sans cette connaissance, chaque question devient une réunion, et le gain de temps disparaît.
L'IA remplace-t-elle la recette d'une application ?
Non. Elle peut rejouer des parcours, prendre des captures d'écran et signaler ce qui casse, y compris la nuit. Mais tester tout le fonctionnel d'une application de santé sur plusieurs téléphones reste un travail humain, et c'est le seul poste du projet dont la durée n'a pas changé.
Quels outils utiliser pour développer une application avec des agents IA ?
Sur ce projet, 4 outils ont compté. Les agents de Claude et de Codex pour écrire le code. Les fiches de méthode « agent-skills » d'Addy Osmani comme base. Un outil de suivi de tickets que les agents lisent et écrivent eux-mêmes. Et une chaîne d'intégration continue Android automatisée dès le départ. Les outils changent tous les 3 mois. La méthode et le harness, décrits dans la section dédiée, non.
Pourquoi le cahier des charges compte plus que l'outil d'IA ?
Parce que l'IA pose des questions en permanence : quel comportement dans ce cas, quelle règle si ce champ est vide, quel écran après celui-là. Quand toutes les réponses existent déjà, elle avance à sa vitesse. Quand il faut les inventer ou les faire valider, elle avance à la vitesse de vos réunions. Sur ce projet, toutes les règles étaient tranchées avant d'ouvrir l'outil, et c'est ce qui a fait la vitesse.
Sources
Références consultées pour cette version du 28 août 2026. Le projet raconté est réel, mené de juin à août 2026 pour DI&Care. Les durées sont celles constatées sur ce projet, pas des moyennes.
Retrouvez tous les Décryptages.