Des specs entrent et du logiciel sort, sans qu’un humain lise le code : c’est la dark factory. Dan Shapiro, CEO de Glowforge, en a fait le dernier niveau de l’échelle qu’il a publiée en janvier 2026. Calquée sur la conduite autonome, cette échelle mesure en six niveaux la maturité d’une équipe dans son usage de l’IA pour développer. Dans cet article, on détaille chaque niveau avec l’analyse d’Olivier Bergeret, le CTO IA de Thiga, qui rapproche les deux derniers de deux façons très différentes d’organiser une équipe Produit.
Fin janvier 2026, Dan Shapiro raconte sur son blog qu'il a vu des dizaines d'entreprises essayer de faire écrire leur code par l'IA. Toutes sont passées par les mêmes paliers. Le schéma lui a rappelé les niveaux d'automatisation de la voiture autonome, définis par l'administration américaine. Comparer une équipe de développement à une voiture qui se conduit toute seule, il fallait y penser !
L'échelle de Dan Shapiro classe donc le développement logiciel assisté par l'IA en six niveaux, de 0 à 5, selon la part du travail que l'IA fait seule. Ça va du niveau 0, où l'IA sert surtout d'outil de recherche, jusqu'à la dark factory du niveau 5.
Chez nous, Olivier Bergeret, qui pilote les sujets de développement agentique, s'en sert souvent dans ses présentations sur l'AI-DLC pour parler d'autonomie de l'IA et d'organisation des équipes. Pour un CPO ou un CTO, c'est en haut de l'échelle que ça devient intéressant. Shapiro s'en tient aux usages de l'IA, et Olivier fait le lien avec l'organisation des équipes. Il rapproche le niveau 4 d'une micro-squad pluridisciplinaire, et le niveau 5 d'un Product Builder.
Sommaire
- Qu'est-ce que l'échelle de Dan Shapiro ?
- Quels sont les six niveaux de l'échelle de Dan Shapiro ?
- Qu'est-ce qu'une dark factory logicielle ?
- Niveau 4 ou niveau 5 : deux façons d'organiser ses équipes
- Pourquoi une échelle d'autonomie n'est pas une échelle de valeur
- Comment situer ses équipes sur l'échelle de Shapiro ?
- FAQ
Qu'est-ce que l'échelle de Dan Shapiro ?
L'échelle de Dan Shapiro est un modèle en six niveaux qui situe une équipe de développement selon la part du travail confiée à l'IA. Shapiro l'a calquée sur les niveaux d'automatisation de la conduite de la NHTSA, l'agence américaine chargée de la sécurité routière.
Le billet s'appelle « The Five Levels »… et pourtant, on compte six niveaux. Rien de mystérieux : comme pour la voiture, la numérotation commence à zéro (entre développeurs, compter à partir de zéro ne choque personne).
Au niveau 0, l'humain écrit tout avec un petit coup de pouce de l'IA ; au niveau 5, la production tourne toute seule.
Ce qui bouge d'un niveau à l'autre, c'est surtout la place de l'humain. Plus on monte, plus il s'éloigne du code, jusqu'au dernier niveau où il ne le lit même plus.
Jusque-là, pour dire où en était une équipe, on avait surtout des formules du genre « on utilise Copilot » ou « on fait un peu de vibe coding », qui ne disent pas grand-chose de la façon dont le travail s'organise. L'échelle de Shapiro donne des repères communs pour en parler.
Quels sont les six niveaux de l'échelle de Dan Shapiro ?
Les six niveaux vont de l'autocomplétion améliorée (niveau 0) à la dark factory (niveau 5). Le tableau reprend les noms donnés par Shapiro et ce que chaque niveau implique pour l'IA et pour l'humain.
| Niveau | Nom chez Shapiro | Ce que fait l'IA | Ce que fait l'humain |
|---|---|---|---|
| 0 | Spicy autocomplete | Sert d'outil de référence, comme un Stack Overflow plus malin | Écrit tout le code et demande à l'IA une réponse ou un bout de code |
| 1 | Coding intern | Écrit du code sans enjeu ou du boilerplate | Demande des fonctions précises, puis relit et intègre aussitôt |
| 2 | Junior developer | Code en binôme, en se passant la main avec l'humain | Relit le code au fur et à mesure qu'il est généré |
| 3 | Developer | Génère l'essentiel du code | Relit tout et devient le goulot d'étranglement de la vérification |
| 4 | Senior developer | Tourne seule pendant de longues périodes sur des tâches complexes | Fait confiance aux vérifications du système et ne contrôle le résultat que bien plus tard |
| 5 | Dark factory | Définit l'implémentation, code, teste, corrige et livre | Pilote les objectifs et le système, pas le code, et décrit ce qu'il veut en langage courant |
Niveaux 0 à 2 : l'humain valide chaque ligne
Au niveau 0, que Shapiro appelle joliment « spicy autocomplete », l'IA sert de Stack Overflow un peu plus malin. Le développeur écrit tout le code, et va juste y chercher une réponse ou un bout de code à coller dans son éditeur en croisant les doigts.
Au niveau 1, l'IA devient un stagiaire : on lui confie du code sans enjeu, typiquement le boilerplate, et on relit tout derrière elle.
Le niveau 2, c'est le développeur junior : on code en binôme avec le modèle, mais on relit encore chaque ligne. Olivier Bergeret y range l'usage le plus courant de Cursor, Claude Code ou Codex, quand l'agent devient un vrai binôme à qui on délègue une partie du développement.
Pas mal d'équipes se reconnaîtront ici. L'IA y fait gagner du temps sans rien bousculer dans l'organisation, parce que chaque ligne passe encore par un humain.
Niveau 3 : le développeur devient relecteur à plein temps
Au niveau 3, l'IA génère la plus grande partie du code, et le développeur passe ses journées à relire des diffs. Le goulot d'étranglement se déplace : l'équipe produit du code plus vite qu'elle ne peut le relire, et la relecture devient le travail principal (l'intitulé de poste pourrait presque devenir « relecteur de diffs à plein temps »).
Niveau 4 : le développeur senior
Au niveau 4, l'humain que décrit Shapiro n'est plus développeur, ni même manager de développeurs. Il est devenu PM, ce qu'il détestait, plaisante-t-il (Product, Project ou Program Manager, Shapiro ne tranche pas). Il écrit la spec, en débat avec l'agent, relit les plans, puis part pour douze heures et revient voir si les tests passent. Shapiro dit lui-même en être là.
Notre CTO IA, lui, appelle ce niveau « spec-driven development ». L'humain définit les specs, les plans et les critères d'acceptation. Les agents développent, testent et corrigent, et l'équipe vérifie les résultats plutôt que chaque ligne de code.
C'est sa lecture du niveau, et elle se défend : dès qu'on ne relit plus tout, la qualité de la spec décide de presque tout le reste.
Qu'est-ce qu'une dark factory logicielle ?
Une dark factory logicielle est une chaîne de production où des agents IA écrivent, testent et corrigent le logiciel, sans qu'aucun humain écrive ni relise le code. Shapiro la décrit comme une boîte noire qui transforme des specs en logiciel.
Le nom vient de l'industrie. Shapiro pense à l'usine de Fanuc, où des robots fabriquent des robots. On peut y éteindre la lumière, parce que les humains n'y sont, écrit-il, ni nécessaires ni bienvenus. Ambiance !
Transposée au logiciel, l'image donne un peu le vertige, et Shapiro pense que c'est sans doute notre avenir. Il dit connaître une poignée de gens qui travaillent déjà comme ça, dans des équipes de moins de cinq personnes.
StrongDM, le cas le plus documenté
Quelques jours après le billet de Shapiro, Simon Willison, développeur et blogueur très suivi sur ces sujets, a raconté la démo qu'il avait vue chez une équipe qui travaillait déjà à ce niveau. Il en retenait trois traits :
- personne n'y relisait le code produit par l'IA ;
- une grande partie du travail des agents allait aux tests, à l'outillage et à la simulation des systèmes voisins ;
- les humains avaient pour rôle de concevoir ce système.
Cette équipe, c'était celle de StrongDM, qui a ensuite rendu publique sa façon de travailler. Sa charte tient en deux règles : le code ne doit pas être écrit par des humains, et il ne doit pas être relu par des humains.
Pour remplacer la relecture, l'équipe écrit des scénarios qui décrivent pas à pas comment un vrai client utiliserait le logiciel. C'est sur eux qu'on vérifie le travail des agents. L'équipe qui décrit cette usine compte trois ingénieurs.
On a tiqué sur deux détails. Le premier, Willison le relevait lui-même : StrongDM fait des logiciels de gestion des accès et de sécurité. C'est à peu près le dernier endroit où on s'attendrait à trouver du code que personne n'a relu.
Le second ferait tousser n'importe quel contrôleur de gestion : son CTO, Justin McCarthy, estime qu'une équipe qui n'a pas dépensé au moins 1 000 dollars de tokens par ingénieur (par jour, oui) a encore de la marge.
Au fond, l'usine tourne grâce au dispositif de vérification que l'équipe a monté autour des agents. On est en plein dans le harness engineering : tout ce qu'on met en place autour d'un agent pour qu'il puisse vérifier lui-même son travail.
Niveau 4 ou niveau 5 : deux façons d'organiser ses équipes
Au niveau 4, une petite équipe pluridisciplinaire écrit et challenge les specs ensemble pendant que l'IA fait le gros du travail. Au niveau 5, un Product Builder pilote les intentions et les résultats, et les agents se chargent de la construction.
C'est la lecture qu'Olivier Bergeret tire de ses missions récentes. Pour lui, la différence entre ces deux niveaux « ne se limite pas à l'autonomie des agents : ils nous emmènent vers deux destinations organisationnelles bien différentes ».
Niveau 4 : la micro-squad pluridisciplinaire
Pour ce niveau, Olivier imagine une micro-squad qui réunit Produit, Tech, QA et Design. L'IA prend en charge les tâches lourdes, complexes ou répétitives, et l'équipe se concentre sur les specs et sur la vérification.
Sur les specs, d'ailleurs, il va assez loin. Il pousse même la micro-squad « à faire générer les spécifications par l'IA à partir d'une intention ou d'une expression de besoin, puis à les challenger collectivement ».
Vous avez peut-être déjà vu un PM boucler seul ses user stories la veille du sprint planning, voire vous l'avez fait vous-même. Dans ce cas, vous mesurez le changement : toute l'équipe discute la spec avant qu'une ligne de code soit écrite.
Même logique pour la vérification, où Olivier fait une grande place à la revue adverse assistée par l'IA. Un modèle y joue l'avocat du diable et cherche activement les failles de ce qui a été produit.
C'est sur ce terrain que notre CTO IA a eu « d'excellentes surprises » lors de ses missions récentes. « En libérant les équipes de cette charge, l'IA remet la discussion, la réflexion collective et les échanges entre Produit et Tech au centre des opérations », raconte-t-il. Il y voit « le retour aux fondamentaux de l'agilité ».
On n'imaginait pas forcément l'IA dans le rôle de celle qui ramène tout le monde autour de la table !
Le mécanisme est pourtant assez simple. Si les agents écrivent l'essentiel du code, le temps de l'équipe passe dans ce qu'ils ne font pas à sa place : se mettre d'accord sur ce qu'il faut construire, puis vérifier que c'est bien ce qui sort.
Niveau 5 : le Product Builder aux commandes
La star du niveau 5 (le mot est d'Olivier), c'est le Product Builder, qu'il vienne du Produit, du Design ou de la Tech. Dans la description qu'il en fait, le Product Builder « pilote les intentions et les résultats du produit, tandis que les agents orchestrent la construction, les tests et les corrections ».
On retombe sur les toutes petites équipes dont parle Shapiro. Chez nous, on voit le Product Builder comme un socle de compétences qui mélange Produit, Design et Tech. Ce mélange permet justement à une seule personne d'aller de l'intention au produit livré avec des agents.
Organiser des équipes autour d'agents, c'est précisément le genre de chantier sur lequel on intervient, alors on ne va pas se priver d'un petit encart.
Repenser vos équipes Produit et Tech autour des agents. Avec le Product Operating Model AI, nos équipes vous aident à adapter votre organisation produit à l'IA, des rôles à la gouvernance.
Pourquoi une échelle d'autonomie n'est pas une échelle de valeur
L'échelle de Shapiro mesure la part du travail que l'IA fait seule, et chaque niveau supplémentaire déplace le contrôle de l'humain vers le système. Ce déplacement a un coût qui change d'un produit à l'autre.
Du coup, comme le résume Olivier Bergeret, « le niveau 5 n'est pas nécessairement supérieur au niveau 4 : l'un privilégie la collaboration humaine, l'autre l'autonomie de la production ».
Ce que la micro-squad du niveau 4 garde, c'est une compréhension partagée du produit : plusieurs personnes ont discuté la spec et ont eu l'occasion d'y repérer le cas limite que tout le monde avait oublié.
Au niveau 5, cette compréhension repose sur le Product Builder et sur ses scénarios de test. Ça va très vite, mais un trou dans la spec ou dans les scénarios peut passer sans que personne le voie.
Et puis il y a le coût d'une erreur. Un bug qui passe entre les mailles d'un outil interne, on le corrige vite et on n'en parle plus. Sur un logiciel de sécurité ou un produit réglementé, c'est une autre paire de manches, et les juristes commencent à s'en mêler.
Un article du CodeX de Stanford consacré à StrongDM relève trois points encore ouverts : qui est responsable d'un code que personne n'a relu, ce qu'il faut en dire aux clients, et comment traiter des contrats qui n'ont pas suivi.
Rien n'empêche une même boîte de faire tourner les deux modèles. On peut imaginer une dark factory pour des outils internes où l'erreur coûte peu, et des micro-squads sur le cœur du produit. Pour Olivier, ces deux manières de construire du logiciel avec l'IA ne s'opposent pas et peuvent coexister.
Comment situer ses équipes sur l'échelle de Shapiro ?
Pour situer une équipe, le plus fiable est de regarder qui écrit le code et qui le relit. Une équipe peut très bien avoir Claude Code sur tous les postes et rester tranquillement au niveau 2, si chaque ligne est relue.
Si les développeurs écrivent encore la plupart du code, avec des suggestions de l'IA, l'équipe se situe entre les niveaux 0 et 2. Dès que l'IA écrit l'essentiel et que la journée des développeurs se passe en revue de diffs, on est au niveau 3.
Le niveau 4 commence quand l'équipe consacre l'essentiel de son temps aux specs et aux critères d'acceptation, et vérifie le comportement du logiciel produit.
Le niveau se lit équipe par équipe. Dans une même boîte, l'équipe plateforme n'a aucune raison d'être au même endroit que celle qui maintient le vieux monolithe que personne n'ose toucher.
Pour passer du niveau 3 au niveau 4, il faut revoir le cycle de développement, parce que la spec et la vérification prennent la place de l'écriture du code. Des cadres comme l'AI-DLC d'AWS ou l'AI-SDLC d'Anthropic aident à le faire sans partir d'une page blanche. Chacun décrit à sa façon ce que font les humains et les agents à chaque phase.
Par contre, on serait bien en peine de dire à quel niveau chaque équipe doit viser. Ça dépend du coût d'une erreur sur son produit et de la part de discussion collective qu'elle veut garder.
Conclusion
Avouons-le, l'usine Fanuc qui tourne lumières éteintes a quelque chose de fascinant. Il a quand même fallu quelqu'un pour en concevoir la chaîne. Chez StrongDM, c'est pareil : les ingénieurs n'écrivent plus le code, ils conçoivent et surveillent le système qui l'écrit.
Pour une direction Produit ou Tech, choisir un niveau pour un produit, ça revient donc à décider qui doit encore se parler avant que le code parte en production.
La micro-squad du niveau 4 garde cette conversation au centre, alors que le Product Builder du niveau 5 la concentre sur une personne et sur ses scénarios. Notre pari, c'est que beaucoup d'organisations auront besoin des deux.
Passer à la pratique avec les agents. Nos formations IA de la Thiga Academy s'adressent aussi bien aux Product Managers et aux Product Designers qu'aux Software Engineers et aux Tech Leads.
FAQ
Qui est Dan Shapiro ?
Dan Shapiro est le CEO de Glowforge, une entreprise américaine, et chercheur associé à la Wharton School. Il a publié son échelle des niveaux de développement assisté par l'IA sur son blog en janvier 2026.
Combien de niveaux compte l'échelle de Dan Shapiro ?
Six, numérotés de 0 à 5. Shapiro parle de « five levels » parce que, comme pour la conduite autonome, le premier niveau porte le numéro 0.
Quelle différence entre la dark factory et le vibe coding ?
Le vibe coding, c'est décrire ce qu'on veut à une IA et accepter le code sans vraiment le lire, souvent pour un prototype. La dark factory se passe elle aussi de la lecture du code, mais elle la remplace par un dispositif de vérification construit pour ça : des specs et des scénarios que le logiciel doit satisfaire.
À quel niveau correspond le spec-driven development ?
Olivier Bergeret, notre CTO IA, l'associe au niveau 4. L'humain définit les specs, les plans et les critères d'acceptation, et les agents développent, testent et corrigent. Chez Shapiro, ce niveau s'appelle « senior developer », et l'humain y travaille déjà sur des specs et des plans.
Faut-il viser le niveau 5 de l'échelle de Shapiro ?
Pas forcément. Le niveau 5 pousse au maximum l'autonomie de la production, alors que le niveau 4 garde la discussion collective entre Produit, Tech, QA et Design. Le bon niveau dépend surtout du coût d'une erreur sur le produit concerné.
