Le Lab IA

Environnement d'ingénierie – Échelon 5 (Usine autonome)

Le Lab IA est un environnement opérationnel parallèle qui cible l'échelon le plus élevé de développement IA. Il accueille les projets terrain vierge (greenfield) et sert de terrain d'épreuve pour les pratiques, agents et workflows qui migreront ensuite vers le reste de l'ingénierie.

Le modèle de travail est le développement non-interactif : les spécifications et scénarios dirigent des agents autonomes qui écrivent, testent et itèrent le code. L'humain définit. L'IA exécute.

Le Lab opère en dehors des standards opérationnels classiques de l'ingénierie. Il a ses propres règles.

Deux échelles de maturité

Ce document utilise deux échelles distinctes. Les confondre crée de l'ambiguïté – elles mesurent des choses différentes.

Échelle organisationnelle (Niveaux 1–3)

Définie dans le cadre de référence, elle s'applique à l'ensemble du groupe – ingénierie, marketing, ventes, finance, service client.

Niveau	Nom	Résumé
1	IA-assisté	L'IA est un outil que les individus choisissent d'utiliser
2	IA-intégré	L'IA est intégrée aux workflows et aux systèmes
3	IA-natif	L'organisation est conçue autour de l'IA comme ressource de premier plan

Échelle d'ingénierie (Échelons 0–5)

Basée sur le cadre de Dan Shapiro, elle décrit la progression spécifique du développement logiciel – du code assisté jusqu'à l'usine autonome (dark factory).

Échelon	Rôle de l'humain	Qui écrit le code	Qui révise le code
0 – Autocomplétion	L'humain code, l'IA suggère la ligne suivante	Humain	Humain
1 – Stagiaire	L'humain assigne des tâches discrètes et scopées	IA	Humain (tout)
2 – Développeur junior	L'humain supervise des changements multi-fichiers	IA	Humain (tout)
3 – Gestionnaire	L'humain dirige, révise au niveau fonctionnalité/PR	IA	Humain (PR)
4 – Chef de produit	L'humain écrit la spécification, vérifie si les tests passent	IA	Personne (tests vérifient)
5 – Usine autonome	La spécification entre, le logiciel sort	IA	Personne (scénarios vérifient)

Correspondance entre les deux échelles

Échelle organisationnelle	Échelle d'ingénierie
Niveau 1 – IA-assisté	Échelons 0–1
Niveau 2 – IA-intégré	Échelons 2–3
Niveau 3 – IA-natif	Échelons 4–5

Le Lab cible l'échelon 5. L'ingénierie hors-Lab vise le Niveau 3 organisationnel (échelons 4–5).

La transition la plus difficile est le passage de l'échelon 3 à l'échelon 4 : accepter de ne plus lire le code et de faire confiance aux scénarios pour valider le résultat. C'est un changement psychologique avant d'être technique. La plupart des ingénieurs plafonnent à l'échelon 3 parce que lâcher le contrôle sur le code va à l'encontre de tous leurs réflexes professionnels.

1. Règles absolues

Deux règles définissent le Lab. Elles ne sont pas des aspirations – elles sont les conditions d'admission.

Le code ne doit pas être écrit par des humains.

Le code ne doit pas être révisé par des humains.

L'humain définit l'architecture, les contraintes et les scénarios de satisfaction. L'IA produit le code, exécute les tests, et converge vers la solution. Si vous êtes en train d'écrire ou de lire du code ligne par ligne, vous n'êtes pas dans le mode de travail du Lab.

2. Conditions d'admission des projets

Projets terrain vierge

Le terrain naturel du Lab. Pas de legacy, pas de dette technique, pas d'habitudes. Les règles du Lab (échelon 5) s'appliquent de bout en bout dès le premier jour.

Critères d'admission :

Le scope est suffisamment défini pour écrire des spécifications et des scénarios
Le projet peut tolérer un rythme d'apprentissage

Projets existants (brownfield) (transition vers l'échelon 5)

Le Lab accueille aussi des projets existants qu'on veut transitionner vers l'échelon 5. C'est plus difficile que le terrain vierge – le code existe, les habitudes aussi – mais c'est là que la transformation a le plus d'impact, parce que c'est là que se trouve la majorité du travail d'ingénierie.

Critères d'admission :

Le projet a une couverture de scénarios suffisante (ou l'équipe s'engage à la construire en premier)
L'équipe accepte que tout nouveau travail (ajouts, modifications, refactoring, revues) suit les règles du Lab – pas de retour au mode classique
Le code existant est traité comme contexte pour l'agent, pas comme intouchable. L'agent peut refactorer, réécrire et restructurer.
Le risque de régression est géré par les scénarios, pas par la revue humaine du code

Séquence type pour un projet existant :

Extraire la spécification implicite – Le système existant EST la spécification. Personne n'a jamais documenté les mille décisions implicites accumulées sur des années de correctifs, de correctifs urgents et de contournements devenus permanents. Cette extraction est le travail le plus difficile et le plus humain de la transition. Elle requiert les gens qui savent pourquoi ce module a cette exception, pourquoi ce service a été découpé de cette façon, pourquoi cette valeur est configurée ainsi. L'IA peut aider à documenter ce que le système fait (générer des spécifications à partir du code). Mais distinguer les comportements intentionnels des accidents historiques reste un jugement humain.
Écrire les scénarios de bout en bout qui décrivent le comportement actuel attendu, basés sur la spécification extraite en étape 1
Vérifier que les scénarios passent sur le code existant
À partir de là, tout changement est fait par l'agent, validé par les scénarios
Itérer : chaque composant transitionné augmente la couverture échelon 5 du projet

Ce qui ne rentre PAS dans le Lab

Tout projet dont le développement continue d'utiliser des pratiques classiques (humain écrit ou révise le code)
Les projets dont les contraintes de livraison ne tolèrent aucun risque d'apprentissage

Règle : la condition d'entrée n'est pas l'absence de code existant – c'est l'engagement que tout nouveau travail suit les règles du Lab.

3. Mode de travail : développement non-interactif

Le cycle

L'humain écrit la spécification (architecture, contraintes, scénarios)
L'agent produit le code
Les scénarios valident le résultat
L'humain évalue la satisfaction et itère sur la spécification si nécessaire

L'humain n'intervient pas dans l'exécution. L'humain intervient dans la définition et l'évaluation.

Scénarios vs tests

Tests : validations stockées dans le code. Vulnérables au gaming par les agents – un agent peut réécrire un test pour le faire passer. Utiles mais insuffisants.
Scénarios : parcours utilisateur de bout en bout qui décrivent le comportement attendu du point de vue de l'utilisateur. Plus difficiles à contourner. Le Lab privilégie les scénarios.

Métrique de satisfaction

Le Lab ne mesure pas le succès en binaire (tests verts / rouges). Il mesure la satisfaction : « parmi toutes les trajectoires observées à travers tous les scénarios, quelle fraction satisfait l'utilisateur ? »

Quand la satisfaction est insuffisante, le problème est dans la spécification, pas dans l'agent. Itérez la spécification, pas le code.

La compétence critique : écrire des spécifications pour un agent

Le goulot d'étranglement du Lab n'est pas la vitesse d'implémentation – c'est la qualité des spécifications. Écrire une spécification assez précise pour qu'un agent l'implémente correctement sans intervention humaine est une compétence nouvelle. Presque personne ne l'a développée.

La difficulté : quand un humain reçoit une spécification ambiguë, il comble les trous avec du jugement, du contexte, ou un message Slack qui demande « tu voulais dire X ou Y ? ». L'agent, lui, construit ce que vous avez décrit. Si la description est ambiguë, le logiciel comble les trous avec des suppositions de machine, pas des intuitions client.

Cette compétence se développe par la pratique :

Les cliniques IA doivent inclure des revues de spécifications : « voici ma spécification, voici ce que l'agent a produit, voici ce qui manquait dans la spécification »
Les binômes doivent travailler sur des exercices de spécification, pas seulement sur des exercices de code
Chaque itération ratée est un signal sur la spécification, pas sur l'agent – documentez ce que la spécification ne disait pas assez clairement

L'objectif du Lab n'est pas seulement de produire du logiciel par agents. C'est de développer des ingénieurs qui savent spécifier avec la rigueur que les agents exigent.

4. Naïveté délibérée

Le plus grand obstacle à l'échelon 5 n'est pas technique – c'est l'habitude.

Les ingénieurs expérimentés ont des réflexes profonds : structurer le code d'une certaine façon, réviser ligne par ligne, écrire les tests eux-mêmes, refactorer manuellement. Ces réflexes étaient des forces en développement classique. Dans le Lab, ce sont des freins.

La naïveté délibérée consiste à :

Retirer les conventions du développement classique et voir ce qui tient sans elles
Se demander systématiquement : « Pourquoi est-ce que JE fais ça ? Le modèle devrait le faire à ma place. »
Accepter que des approches qui semblent « naïves » ou « incorrectes » selon les standards classiques peuvent être correctes dans un environnement IA-natif
Traiter les tâches historiquement jugées trop coûteuses (construire des répliques complètes de services, écrire des milliers de scénarios) comme routinières quand le coût d'exécution IA le permet

La question permanente du Lab :

Pourquoi est-ce que je fais ça ? Le modèle devrait le faire à ma place.

Si la réponse est « parce que j'ai toujours fait comme ça », c'est exactement la raison de changer.

5. Rôle de support

Le Lab n'est pas isolé du reste de l'ingénierie. Il la sert.

Le Lab produit :

Des patrons (patterns) de travail documentés : comment spécifier pour un agent, comment écrire des scénarios, comment évaluer la satisfaction
Des agents réutilisables ou adaptables
Des preuves concrètes que l'échelon 5 fonctionne sur de vrais projets
Des retours d'expérience honnêtes – ce qui marche et ce qui ne marche pas encore

Le Lab partage via :

Cliniques IA : sessions régulières, format court. « Voici ce qu'on a essayé, voici ce qui s'est passé. »
Documentation : chaque patron et anti-patron découvert est documenté
Binômes Lab / hors-Lab : un membre du Lab travaille temporairement avec un ingénieur hors-Lab pour transférer les pratiques

Le Lab qui ne partage pas ne sert à rien. Le partage est aussi important que la production.

6. Signal économique

Un signal concret que le Lab opère à l'échelon 5 : le budget en jetons (tokens) IA.

Si une équipe dans le Lab ne dépense pas significativement en jetons par jour, elle ne fait probablement pas travailler les agents – elle fait le travail elle-même.

Le budget en jetons est un indicateur de charge de travail IA, pas un objectif en soi. Mais si les jetons sont proches de zéro, l'humain fait le travail de l'agent, et les règles absolues du Lab ne sont pas respectées.

7. Culture du Lab

Le Lab a une culture distincte du reste de l'organisation :

Curiosité obligatoire – la question « et si on essayait... » est toujours bienvenue
Veille agressive – les membres du Lab sont à l'affût des derniers avancements des modèles IA. Quand un nouveau modèle ou un nouvel outil sort, le Lab le teste rapidement et évalue s'il change la donne. Attendre que « ça mûrisse » n'est pas compatible avec le Lab.
Audace sur les méthodes, rigueur sur les engagements – le Lab pousse les limites sur comment on travaille : quels outils on adopte, quels workflows on réinvente, quelles approches « naïves » on teste. Mais les obligations contractuelles, économiques, légales et de sécurité envers les clients restent non négociables. L'audace porte sur les moyens, pas sur les garanties.
Risque élevé, enjeux bas – les projets du Lab sont choisis pour tolérer l'échec. Profitez-en pour prendre des risques que vous ne prendriez pas ailleurs
Transparence radicale – les échecs sont partagés avec autant de détail que les succès. Un échec documenté a plus de valeur qu'un succès silencieux
Le leadership, c'est élever l'équipe – dans le Lab, le leadership ne se mesure pas à la performance individuelle. Les leaders sont ceux qui rendent le reste de l'équipe meilleur : qui partagent leurs découvertes, qui documentent leurs patrons, qui débloquent leurs collègues, qui transforment leur expertise en pratiques reproductibles. Un ingénieur brillant qui garde ses méthodes pour lui n'est pas un leader du Lab.
Vitesse d'itération – la boucle spécification → agent → scénario → évaluation doit être rapide. Si une itération prend des jours, le cycle est trop lourd

8. Pièges à éviter

Revenir aux habitudes – le réflexe de « vérifier le code manuellement juste pour être sûr » est exactement ce que le Lab interdit. Si les scénarios passent, le code est validé par les scénarios.
Spécifications insuffisantes – quand l'agent produit du mauvais code, le problème est dans la spécification. Itérez la spécification, pas le code.
Isolation – le Lab qui ne partage pas ses apprentissages est un hobby, pas un Lab.
Projets trop critiques trop tôt – le Lab a une tolérance au risque élevée. N'y mettez pas un projet dont l'échec met en danger un client ou un contrat.
Perfectionnisme de l'agent – l'objectif n'est pas un agent parfait. C'est un agent qui produit de la valeur. Itérez.
Projet existant sans extraction de spécifications – transitionner un projet existant sans d'abord extraire la spécification implicite et écrire les scénarios qui protègent le comportement actuel, c'est voler sans filet. L'extraction est le travail le plus dur – ne le sous-estimez pas.
Projet existant « à moitié Lab » – si une partie du travail sur un projet existant est faite en mode classique « parce que c'est plus rapide pour cette partie-là », le projet n'est pas dans le Lab. Les règles sont absolues, même quand c'est inconfortable.

9. Cycle de vie

Phase 1 : Le Lab démarre avec des projets terrain vierge (terrain le plus naturel) et commence la transition de 1–2 projets existants sélectionnés. Équipe restreinte. Règles absolues en vigueur. Résultat = projets livrés + pratiques documentées + agents fonctionnels + manuel de transition projet existant.
Phase 2 : Les projets existants transitionnés au Lab deviennent les cas de référence pour le reste de l'ingénierie. Les ingénieurs qui sont passés par le Lab deviennent les binômes pour ceux qui n'y sont pas encore passés. D'autres projets existants entrent au Lab.
Terme : Le Lab a absorbé l'ingénierie. La distinction disparaît. Tout est échelon 5. Le Lab n'était pas une destination – c'était le véhicule de transition. Les projets terrain vierge ET projets existants opèrent selon les mêmes règles.

Règle de synthèse

Pourquoi est-ce que je fais ça ? Le modèle devrait le faire à ma place.

Si la réponse est « parce que j'ai toujours fait comme ça », c'est exactement la raison de changer.

← Retour à l'accueil · Le cadre de référence · Standards d'exécution · Glossaire