Par Loic Baconnier.
Avec l’IA, le code s’écrit vite. Une fonctionnalité prend forme en quelques échanges, un agent explore un dépôt, propose une modification et lance des tests. Mais cette vitesse fait apparaître une autre difficulté : savoir précisément quoi construire, comment le vérifier et dans quelles conditions le mettre en production.
Le goulot d’étranglement se déplace vers la planification, la spécification, les tests et la gouvernance. C’est le point de départ de ma masterclass « L’Usine à IA & le SDLC IA-Native ». Cette vidéo introduit les principes de l’Usine à IA. La masterclass les approfondit ensuite en quatre grandes parties.
Produire du code ne suffit pas à produire un logiciel
Un agent peut générer une implémentation convaincante à partir d’une demande ambiguë. Il peut aussi réussir des tests qui ne couvrent pas le besoin réel. Dans les deux cas, l’activité est visible : des fichiers changent, des commandes passent, une réponse annonce que le travail est terminé.
La question reste pourtant ouverte : le résultat répond-il au problème de départ ?
Accélérer la construction rend cette question plus pressante. Une mauvaise hypothèse peut désormais se transformer très rapidement en une quantité importante de code. Le temps gagné à écrire risque alors d’être consommé à relire, corriger ou reconstruire.
La vitesse de génération devient utile lorsque l’équipe sait reconnaître un résultat acceptable.
L’Usine à IA désigne ici une organisation du travail : une intention explicite, des artefacts partagés, des agents encadrés et des preuves adaptées au résultat attendu. Chaque étape doit préparer la suivante et conserver assez de contexte pour que les décisions restent compréhensibles.
Quatre parties pour relier intention, exécution et vérification
1. Un workflow en six phases et une chaîne d’artefacts
La première partie suit six phases : planification, design et spécifications, construction, tests, déploiement, puis maintenance. Elle s’appuie sur une chaîne simple : intent.md → spec.md → plan.md. Le premier document clarifie le problème et l’intention ; le deuxième décrit les comportements attendus et les contraintes, notamment de sécurité ; le troisième organise l’implémentation. Les tests apportent ensuite des preuves, le déploiement passe par les validations nécessaires et les incidents de maintenance alimentent le cycle suivant. L’intérêt de ces fichiers tient à leur continuité : conserver le sens de la demande jusqu’au logiciel livré.
2. Une architecture et une gouvernance pour les agents
La deuxième partie examine le cadre dans lequel les agents travaillent. Une architecture distinguant présentation, services et persistance rend les responsabilités plus lisibles. La mémoire d’équipe conserve les conventions ; les skills apportent des compétences ciblées ; les hooks peuvent faire respecter des règles déterministes ; les fiches ADR gardent la justification des décisions d’architecture. L’ingénieur-architecte organise cet environnement, délimite l’autonomie et conserve la responsabilité des arbitrages. Une consigne écrite et un contrôle technique n’offrent pas les mêmes garanties : leur rôle doit être explicite.
3. Des objectifs et des évaluations pour guider l’exécution
La troisième partie passe du contexte fourni à l’agent à la définition du résultat recherché. Donner davantage d’informations ne suffit pas si l’état final reste vague. L’ingénierie par les objectifs précise ce qui doit être obtenu ; les évaluations permettent de mesurer l’écart. Des suites d’épreuves, des benchmarks métier et des métriques alimentent alors les boucles de correction. Leur valeur dépend de leur représentativité : un indicateur facile à améliorer peut rester éloigné du besoin utilisateur. Il faut donc définir les critères de réussite, les limites de l’itération et les situations qui nécessitent une décision humaine.
4. Une architecture multi-modèles et une économie mesurée
La quatrième partie aborde le choix des modèles selon les tâches : cadrage, planification, production de code ou relecture. Elle explore les modèles stratégiques, locaux et spécialisés, la validation croisée, le routage, le cache de contexte et les architectures hybrides. L’arbitrage porte sur la qualité, le coût, la latence et les contraintes d’hébergement. Multiplier les modèles ajoute aussi de la coordination. Le bon assemblage doit donc être évalué sur le travail réellement accepté, en tenant compte des reprises et de l’exploitation, plutôt que sur le seul prix d’un appel.
Ce qui change dans le travail de l’équipe
Prenons une demande simple : ajouter un export de données.
Avant de déléguer le développement, plusieurs décisions doivent être prises. Qui peut exporter ? Quels champs sont autorisés ? Quel volume faut-il supporter ? Que se passe-t-il lorsque l’opération échoue ? Comment vérifier que les données sensibles restent protégées ?
Ces questions orientent directement l’implémentation. Elles permettent aussi de construire une vérification utile. Un bouton qui télécharge un fichier constitue une première observation ; un export conforme aux droits, aux données attendues et aux contraintes de volume apporte une preuve beaucoup plus solide.
La chaîne d’artefacts rend ces décisions consultables. L’agent dispose d’un cadre, la personne qui relit comprend les choix et l’équipe peut retrouver pourquoi une solution a été retenue.
Cela demande de la discipline, mais chaque document doit avoir une fonction concrète. Une spécification utile réduit une ambiguïté. Un plan utile rend l’exécution contrôlable. Une évaluation utile détecte un écart qui compte.
Garder un cadre proportionné
Une usine efficace doit aussi savoir s’arrêter. Ajouter des agents, des règles et des revues peut finir par augmenter le travail sans améliorer le résultat.
Pour une correction limitée, quelques critères et les tests existants peuvent suffire. Un changement qui touche aux données, aux droits d’accès ou au déploiement appelle davantage de contrôles. Le niveau de gouvernance doit suivre les conséquences possibles de l’action.
Le même raisonnement s’applique à l’autonomie. Une équipe doit savoir ce que l’agent peut exécuter seul, ce qui exige une validation et quand une incertitude doit être remontée. Ces limites rendent la délégation plus claire pour tous.
Le rôle humain se concentre alors sur des décisions essentielles : choisir le problème, arbitrer les contraintes, juger les preuves et autoriser les étapes engageantes.
Pour qui ?
Cette masterclass s’adresse aux développeurs qui utilisent déjà l’IA et souhaitent mieux structurer leur pratique, ainsi qu’aux tech leads et architectes qui doivent intégrer les agents dans un environnement collectif.
Elle concerne aussi les responsables produit, les équipes qualité et les décideurs techniques. La définition du besoin, les critères d’acceptation et la responsabilité de mise en production traversent plusieurs métiers.
La vidéo d’introduction donne une vue d’ensemble avant d’entrer dans les mécanismes. Elle permet de situer les sujets et de comprendre pourquoi le cycle de vie logiciel — le SDLC — reste le fil conducteur du parcours.
Une masterclass pour comprendre et mettre en pratique
Cette masterclass propose un parcours progressif pour structurer le développement logiciel avec les agents IA : partir d’une intention claire, organiser le travail, vérifier les résultats et maîtriser les choix techniques et économiques.
Suivre la masterclass
Cette introduction pose la question qui traverse tout le parcours : lorsque la production de code s’accélère, comment garder la maîtrise du logiciel que l’on construit ?
Les quatre parties relient le workflow, l’architecture, les évaluations et les choix économiques. L’objectif est de disposer d’un cadre pour décider où l’IA apporte de la valeur et comment vérifier cette valeur.
Suivez la playlist « L’Usine à IA & le SDLC IA-Native » sur YouTube pour retrouver l’introduction et suivre la mise à disposition de la suite.
