Le Lab IA
Un environnement d'ingénierie de pointe où la spécification entre et le logiciel sort.
Environnement d'ingénierie – Échelon 5 (Production autonome)
Le Lab IA est un environnement opérationnel parallèle ciblant l'échelon le plus élevé de développement IA. Il expérimente de nouvelles façons de faire et sert d'espace de test pour les pratiques, agents et flux de travail qui seront ensuite appliqués dans l'ingénierie. Le Lab opère en dehors des standards opérationnels classiques. Il a ses propres règles.
Deux échelles de maturité
Ce document utilise deux échelles distinctes définies dans le cadre de référence : l'échelle organisationnelle (Niveaux 1–3, applicable à toute l'entreprise) et l'échelle d'ingénierie (Échelons 0–5, spécifique au développement logiciel). Voir le cadre pour les définitions complètes et les critères d'acceptation.
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.
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
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.
- Le scope est suffisamment défini pour écrire des spécifications et des scénarios
- Le projet peut tolérer un rythme d'apprentissage
Le Lab accueille aussi des projets existants qu'on veut transitionner vers l'échelon 5. C'est plus difficile — le code existe, les habitudes aussi. Mais c'est là que la transformation a le plus d'impact.
- Couverture de scénarios suffisante (ou engagement à la construire)
- Tout nouveau travail suit les règles du Lab, pas de retour au mode classique
- Le code existant est contexte pour l'agent, pas intouchable
- Régression gérée par les scénarios, pas par la revue humaine
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.
Quand l'humain ne lit plus le code, les tests unitaires perdent un avantage crucial : la capacité de l'ingénieur à identifier les cas limites à partir de sa connaissance de l'implémentation. Dans un modèle d'exécution opaque, seule la validation comportementale de bout en bout reste fiable, parce qu'elle ne dépend pas de la connaissance des détails internes.
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. 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 flux de travail 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.
7. 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 ;
- Le mur des six mois : les projets IA sans implication humaine forte (spécification, scénarios, architecture) accumulent une dette structurelle qui explose après environ six mois. Le code généré par l'IA sans contraintes claires est souvent moins structuré et moins maintenable. Les scénarios et les spécifications du Lab sont précisément la défense contre ce mur : ils imposent une rigueur en amont qui empêche la dette de s'accumuler silencieusement.
8. Cycle de vie
Le Lab démarre avec des projets terrain vierge 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.
Les projets existants transitionnés au Lab deviennent les cas de référence pour le reste de l'ingénierie. Les ingénieurs passés par le Lab deviennent les binômes pour ceux qui n'y sont pas encore. D'autres projets existants entrent au Lab.
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. Projets terrain vierge ET existants opèrent selon les mêmes règles.
Ce cycle de vie s'aligne sur le chemin de transformation organisationnel : la Phase 1 correspond à la transition Niveau 2→3 (6–12 mois à l'échelle organisationnelle).
Règle de synthèse
Pourquoi est-ce que je fais ça ? Le modèle devrait le faire à ma place.
← Retour à l'accueil · Le cadre de référence · Standards d'exécution · Glossaire