« Ne mettez pas le nouveau moteur dans la vieille usine. » C’est ainsi que Jenny Patchen a conclu une conférence à GitHub Universe 2026. Patchen occupe un poste de senior director chez Levi Strauss & Co. L’équipe a d’abord redessiné tout son processus de développement, puis construit 17 agents IA adaptés au nouveau. La première appli construite ainsi a pris deux mois et demi au lieu de neuf.
La plupart des équipes font l’inverse. Elles ajoutent un agent de code au processus qu’elles ont déjà, et attendent les gains. Cette conférence est l’une des rares à montrer ce qui vient avant les agents. Trois jours dans une salle, une carte de chaque étape, et une règle pour savoir qui décide quoi.
La vieille usine vient d’une histoire que Patchen raconte en ouverture. Quand l’électricité est arrivée dans les usines, l’économiste Paul David a constaté que la productivité ne bougeait pas. Les patrons ont remplacé la machine à vapeur par un moteur électrique et gardé tout le reste. Il a fallu des décennies, et de nouveaux ateliers pensés pour l’électricité, avant que la production augmente. « C’est la même vieille usine avec un nouveau moteur », dit Patchen. Selon la conférence, c’est là qu’en sont la plupart des équipes avec les agents aujourd’hui.
Douze passages de relais, surtout de l’attente
L’équipe est partie de ce qui n’allait pas, pas des outils. L’appli s’appelle Back Pocket, et les vendeurs de Levi’s l’utilisent en magasin. Elle les aide à servir les clients, par exemple en commandant une taille que le magasin n’a pas. Sa première version avait pris neuf mois.
Le produit, l’ingénierie, la qualité et l’équipe de productivité des développeurs ont passé trois jours dans une même salle, ordinateurs presque toujours fermés. Le premier jour, ils ont cartographié le processus tel qu’il était. Le deuxième, ils ont dessiné l’avenir qu’ils voulaient. Le troisième, ils ont listé ce qu’il fallait pour y arriver.
La carte avait quatre étapes : planifier, construire, vérifier et livrer. Elle comptait 12 passages de relais entre six rôles, et un changement prenait souvent des mois du début à la fin. Deux étapes duraient le plus longtemps. Écrire la user story prenait deux à quatre semaines, parfois des mois, à cause de toutes les équipes concernées. Les tests et la non-régression prenaient trois semaines, toujours à la fin, donc chaque problème trouvé obligeait à revenir en arrière.
L’essentiel de ce temps passait à attendre. La question a donc changé. Ce n’était plus « comment faire travailler les gens plus vite ? ». C’est devenu « comment arrêter d’attendre ? ».
L’ancien processus : 12 relais, six rôles
Deux étapes bloquaient le travail pendant des semaines
- PlanifierÉcrire la user story : deux à quatre semaines, parfois des mois.
- ConstruireLe code, une fois la story écrite.
- VérifierTests et non-régression : trois semaines, toujours à la fin.
- LivrerEn magasin.
L’essentiel du temps passait à attendre. La nouvelle question : comment arrêter d’attendre ?
Les agents font, les personnes décident
La décision clé a été une grille. Chaque étape de l’ancienne carte est devenue un résultat attendu. Chaque résultat a reçu trois colonnes de plus : ce que fait l’IA, ce que fait une personne, et ce que décide une personne.
Prenez les exigences. L’étape était « écrire les exigences ». Le résultat attendu est « des exigences claires, transverses et partagées ». L’IA écrit des exigences testables et liste les dépendances. Une personne apporte les idées et vérifie ce que l’agent a écrit. Une personne fixe les priorités et valide.
Patchen présente cette séparation entre « l’humain fait » et « l’humain décide » comme l’un de leurs choix les plus importants. Le faire peut se partager avec des agents. La décision reste à une personne, qui reste donc responsable. La règle de l’équipe : les agents exécutent, les humains décident.
La colonne « l’IA fait » devient ensuite la fiche de poste de l’agent. Avant d’en construire un, l’équipe répond à cinq questions. Qu’est-ce qui le déclenche ? Que reçoit-il en entrée ? Que fait-il ? Que produit-il ? Et qui prend la suite ? Reprenez l’agent des exigences. Une demande de fonctionnalité arrive. L’agent lit le ticket et le modèle de spec. Il écrit des exigences testables, et pose une question quand quelque chose n’est pas clair. Il en sort une spec sur laquelle toute l’équipe peut construire. Puis une personne merge la pull request qui valide la spec.
Un résultat dans la grille : les exigences
Les agents peuvent faire le travail, seule une personne décide
- Le résultatDes exigences claires, transverses et partagées.
- L’IA faitÉcrit des exigences testables et relève les dépendances.
- L’humain faitApporte les idées, et vérifie ce que l’agent a écrit.
- L’humain décideFixe les priorités et valide.
La couche « l’IA fait » devient l’agent des exigences.
Un agent, c’est un fichier Markdown
C’est seulement ensuite que l’équipe a construit la plateforme, faite surtout de texte. Les développeurs gardent les outils qu’ils utilisent déjà : GitHub, VS Code et Copilot en ligne de commande. Un agent d’orchestration répartit le travail entre 17 agents spécialisés. La conférence en nomme trois : exigences, tests et observabilité. Les 14 autres couvrent des domaines comme la sécurité et l’accessibilité.
Chaque agent est un fichier Markdown. Un court en-tête dit ce qu’il est, puis des instructions en clair disent ce qu’il peut faire et ce qu’il ne peut pas faire. Tout le monde dans l’équipe peut en lire un et proposer une meilleure version. Les fichiers sont dans un dossier agents au niveau de l’organisation GitHub, donc chaque dépôt les reçoit sans configuration. Une modification d’agent passe par une pull request comme du code : relue, versionnée et traçable. Le même fichier fonctionne sur github.com, en ligne de commande et dans VS Code.
Les agents atteignent les outils externes par des serveurs MCP. MCP (Model Context Protocol) est une façon standard de brancher un outil sur un modèle d’IA. L’agent des exigences utilise Jira et Confluence. L’agent d’observabilité utilise New Relic. L’agent de tests pilote un navigateur avec Playwright. Figma, GitHub et Context7, un service de documentation, sont branchés aussi. « Quand ces systèmes changent, on change le branchement, dit Patchen. On ne change pas l’agent. »
Sous l’ensemble tourne Copilot cloud agent, l’agent de GitHub qui travaille sur une branche dans le cloud. Patchen décrit les 17 agents comme « au fond, des prompts spécialisés » qui tournent dessus. Des skills partagés, des instructions packagées que n’importe quel agent peut charger, portent les standards de l’entreprise.
La plateforme d’agents de Levi’s, de haut en bas
Dix-sept agents, chacun un fichier texte
- Là où travaillent les développeursGitHub, VS Code et Copilot en ligne de commande, les outils qu’ils avaient déjà.
- Agent d’orchestrationRépartit le travail dans l’équipe d’agents.
- 17 agents spécialisésChacun un fichier Markdown dans le dossier agents de l’organisation, modifié par pull request.
- Serveurs MCPJira, Confluence, New Relic, Playwright, Figma, GitHub, Context7.
- Le moteurCopilot cloud agent, avec des skills partagés pour les standards.
Quand un outil change, on change le branchement, pas l’agent.
Deux arrêts pour une personne
Un agent seul aide, mais le gain vient de leur enchaînement. Dans le flux de Levi’s, un changement passe par une chaîne d’agents et ne s’arrête que deux fois pour une personne.
Tout commence par l’agent des exigences. Il écrit la spec en EARS (Easy Approach to Requirements Syntax). EARS est un modèle de phrase fixe, du type « quand ceci arrive, le système doit faire cela ». Chaque ligne se traduit alors presque directement en test. L’agent a pour consigne de demander dès que quelque chose n’est pas clair. Les agents ont tendance à foncer avec une confiance totale et à livrer autre chose que ce qui était voulu, et une question à ce moment-là évite de refaire le travail plus tard.
Une personne valide la spec en mergeant sa pull request. C’est le premier arrêt. Copilot cloud agent construit ensuite le changement et ouvre une pull request. Des spécialistes optionnels peuvent passer ensuite ; les 17 ne tournent pas sur chaque changement.
Viennent ensuite les contrôles qualité, qui tournent toujours, dans un ordre fixe : tests, accessibilité, performance, revue de code et sécurité. La sécurité passe en dernier exprès, pour voir tous les changements faits par les autres agents. L’agent d’observabilité ajoute le monitoring qui manque, pour que le code apparaisse dans New Relic. Un agent de déploiement optionnel propose la façon de déployer. Puis une personne relit et merge. C’est le deuxième arrêt.
La description de la vidéo indique que chaque pull request est relue par cinq à onze agents. Chacun corrige ce qu’il trouve et pousse la correction sur la branche, dans un commit étiqueté. La personne qui relit reçoit un seul résumé de ce que chaque agent a changé, puis décide.
Un changement, de la demande au merge
Une personne intervient deux fois, les agents font le reste
- AgentSpecLes exigences en EARS. Il demande quand ce n’est pas clair.
- PersonneValider la specMerge la pull request de la spec.
- AgentConstruireCopilot cloud agent écrit le changement et ouvre une pull request.
- AgentsContrôlesTests, accessibilité, performance, revue de code, sécurité en dernier.
- AgentObserverAjoute le monitoring manquant pour New Relic.
- PersonneMergerLit un seul résumé de toutes les corrections, puis merge.
Des spécialistes optionnels et un agent de déploiement peuvent s’ajouter ; les 17 ne tournent pas à chaque fois.
J’ai défendu cette forme dans Relisez le plan, pas la pull request. La première personne de la boucle lit la spec, avant qu’il existe la moindre ligne de code. Cela répond aussi à ma note sur l’usine logicielle agentique. Là, les agents de code avaient remplacé la case du développeur et gardé toutes les autres cases du pipeline de 2022, si bien que la revue était devenue l’étape lente. Levi’s a d’abord redessiné les cases.
Des standards en contrôles, pas en rappels
Le troisième objectif était des standards « intégrés, pas ajoutés après coup ». Levi’s avait écrit ce qu’est le bon niveau en sécurité, accessibilité, performance et monitoring. Mais un standard ne marche que si chaque ingénieur pense à l’appliquer. Chacun est donc devenu un agent qui le vérifie sur chaque pull request et corrige ce qu’il trouve.
L’agent de sécurité vérifie la liste OWASP des risques web courants et les vulnérabilités connues, cherche les secrets, et corrige par ordre de gravité. L’agent d’accessibilité vérifie le niveau WCAG 2.2 AA dans un vrai navigateur, avec Playwright. L’agent de performance mesure les Core Web Vitals, les indicateurs de vitesse de page de Google, dans le navigateur lui aussi. La règle de Patchen : toujours mesuré, jamais estimé, avant de corriger quoi que ce soit. L’agent d’observabilité ajoute le monitoring qui manque.
La même idée traverse les dépôts. Levi’s a dix modèles de départ pour les nouveaux dépôts, dont neuf pour des langages allant de TypeScript à Swift. Chacun arrive avec le pipeline de build, la documentation, les runbooks et un fichier AGENTS.md. Les agents connaissent donc le dépôt dès qu’ils y arrivent. Chaque pull request passe aussi des contrôles dans la CI : revue des dépendances, tests, couverture et une vérification préalable New Relic. « On ne peut aller vite que si on a de bons freins », dit Patchen. Pour les dépôts existants, un agent les compare aux modèles et ouvre des pull requests pour combler les écarts.
Tout est partagé dans une marketplace interne à quatre rayons : agents, skills, prompts et serveurs MCP. Elle contient 24 agents, 19 skills et 15 serveurs MCP. Les ingénieurs qui les utilisent les notent avec des étoiles et des commentaires, et chacun s’installe en un clic.
Ce que vérifient les agents de contrôle
Chaque standard est vérifié sur chaque pull request
StandardVérifié, puis corrigé
SécuritéRisques OWASP et vulnérabilités connuesPlus une recherche de secrets, corrigés par gravité
AccessibilitéWCAG 2.2 AADans un vrai navigateur, avec Playwright
PerformanceCore Web VitalsMesurés dans le navigateur, jamais estimés
ObservabilitéLe monitoring manquantAjouté pour que le code apparaisse dans New Relic
La CI lance aussi revue des dépendances, tests, couverture et vérification New Relic.
Les outils étaient la partie facile
« Les outils étaient vraiment la partie facile », dit Patchen. Le gros du travail a été d’accompagner les gens dans un changement de leur métier même. L’équipe avait de vraies inquiétudes.
Quatre choses ont aidé. Avant l’atelier, chacun a reçu une lecture préparatoire sur ce que faisaient d’autres entreprises, avec des études de Gartner et de McKinsey. Le but : viser un nouveau processus, pas de petites retouches. Un ingénieur principal qui connaît l’IA a rejoint l’équipe comme entraîneur-joueur : à chaque stand-up, sur leur chat, prêt à aider sur ce qui coinçait. La formation se faisait sur le code de l’équipe, pas sur des exercices dans un bac à sable. Et des permanences ouvertes donnaient à chacun un endroit sûr pour poser ses questions.
Le plus dur était pour les meilleurs. Patchen cite une étude de Korn Ferry : les plus performants ont souvent le plus de mal avec l’IA. Les compétences qui ont fait leur carrière sont celles qu’ils doivent maintenant lâcher. Les nouvelles habitudes : écrire la spec d’abord, et lire d’un œil critique ce que produit l’agent. Même le stand-up a changé. Il ne sert plus à faire le point sur l’avancement, mais à parler des décisions et des exceptions.
L’équipe a aussi écrit quatre règles, « assez courtes pour s’en souvenir et assez nettes pour trancher un débat ».
Les règles de l’équipe Levi’s
Quatre règles, assez courtes pour trancher un débat
RègleCe qu’elle veut dire
JugementLes humains jugent, les agents exécutentLes personnes prennent le travail flou, qui demande du goût
ContexteIl vit là où les agents le voientLe dépôt et le ticket restent. Le chat, non
Une barreLa même barre pour agents et humainsTout passe les mêmes contrôles
TraceTraçable, toujoursChaque action d’agent et chaque reprise humaine est journalisée
La règle du contexte est celle que je copierais en premier. Une décision prise dans un fil de chat est perdue pour l’agent suivant. Une décision écrite dans le ticket ou le dépôt reste là pour chaque agent et chaque personne qui suit. Patchen s’attend à ce que le chat devienne bientôt un contexte utilisable, mais dit qu’ils n’en sont pas là, et ils l’ont dit à l’équipe.
Plus vite, et mieux aussi
Le chiffre phare, c’est le lancement. La nouvelle Back Pocket a pris deux mois et demi, contre neuf pour l’ancienne, soit 72 % de temps en moins. Elle est en cours de lancement en Asie du Sud-Est.
L’équipe s’attendait à une baisse du débit, le temps que chacun apprenne la nouvelle façon de faire. Il a augmenté de 51 % à la place. Un taux de réussite a progressé de 54 %, ce que Patchen lit comme une hausse de la qualité en même temps. Vitesse et qualité s’opposent souvent, donc les voir monter ensemble est rare. La conférence ne dit pas ce que compte chaque chiffre : des changements, des stories ou des exécutions de tests.
Patchen se méfie du débit pris seul. Plus de production par les agents ne veut pas toujours dire de meilleurs résultats. La réponse de la conférence, c’est la date de lancement : le produit est arrivé en magasin bien plus tôt. Pendant ce temps, la part des pull requests faites avec l’IA est passée de 26 % à 69 % sur la même courte période. L’objectif est 100 %.
Back Pocket, l’ancienne façon contre la nouvelle
Neuf mois sont devenus deux mois et demi
72 %de temps de construction en moins : 2,5 mois contre 9
+51 %de débit, alors que l’équipe attendait une baisse
+54 %de taux de réussite, lu comme une hausse de la qualité
69 %des pull requests faites avec l’IA, contre 26 %
La conférence ne dit pas ce que comptent le débit et le taux de réussite.
Ce qu’ils ont changé en route
Le flux que j’ai décrit n’est pas celui de départ. Au début, chaque agent de revue travaillait sur la pull request en parallèle. Cela créait des conflits de merge, alors ils ont fait passer les agents l’un après l’autre. Très récemment, ils ont encore changé. Désormais chaque agent laisse des commentaires, et un agent assistant, à la fin, les lit tous et fait les corrections. On garde l’essentiel de la vitesse, sans les conflits.
L’atelier a changé aussi. Trois jours en salle, plus à peu près autant d’heures de préparation, cela a bien marché mais coûté cher. Patchen l’a depuis mené avec de nouvelles équipes en seulement trois heures, avec de bons résultats.
Comment les agents de revue se partagent une pull request
Des corrections en parallèle à des commentaires et un seul correcteur
- Au débutTous en parallèleChaque agent corrigeait la même pull request en même temps. Conflits de merge.
- EnsuiteL’un après l’autrePlus de conflits. Chaque agent commite sa propre correction.
- Aujourd’huiCommentaires, un correcteurChaque agent commente. Un agent assistant les lit tous et corrige.
À vous d’essayer
La conférence dure 30 minutes, en anglais. La grille de qui fait et qui décide commence vers 6:50, l’architecture à 9:46, et les leçons à 27:30.
- GitHub, 17 agents, one SDLC: How Levi Strauss reimagined development on GitHub, Jenny Patchen à GitHub Universe 2026.
- Relisez le plan, pas la pull request, sur le contrôle humain placé sur la spec.
- L’usine logicielle agentique, c’est celle de 2022 avec une seule case changée, la même vieille usine avec un nouveau moteur.
- Comment l’équipe Claude Code relit le code qu’écrit Claude, une autre équipe avec plusieurs agents de revue sur un même changement.
Ensuite, essayez la grille sur une étape de votre propre processus. Écrivez son résultat attendu, ce qu’un agent pourrait faire, ce qu’une personne fait encore, et ce qu’une personne doit décider. Si la dernière colonne reste vide, dites-moi de quelle étape il s’agit.
Texte brut: levi-strauss-rebuilt-the-process-before-the-agents.md · Flux Atom · Toutes les notes