OpenAI a publié le 18 août 2026 un retour d’expérience consacré à la suppression d’Enzyme dans la base de code d’Asana avec Codex. L’étude de cas annonce environ deux semaines calendaires, une semaine et demie d’effort d’ingénierie et 12 000 dollars de coûts de modèles et d’infrastructure. Ces chiffres sont impressionnants, mais ils doivent être lus comme un cas fournisseur, pas comme une promesse applicable à chaque migration.
1. Ce que le cas Asana affirme
Selon le retour publié par OpenAI au sujet d’Asana, l’équipe a retiré Enzyme, un système de test devenu une dette importante, en environ deux semaines calendaires. Le travail humain direct aurait représenté une semaine et demie, tandis que le coût des modèles et de l’infrastructure serait d’environ 12 000 dollars.
L’article compare ce résultat à un ancien plan qu’Asana estimait à au moins cinq ans et environ 6 millions de dollars de personnel. Cette comparaison provient de l’organisation elle-même et dépend de la méthode d’estimation retenue. Elle ne doit pas être transformée en ratio générique de productivité ni en comparaison de coûts complets indépendamment auditée.
L’information la plus utile est opérationnelle : à partir d’un prompt initial de cinq phrases, jusqu’à quatre agents travaillaient en parallèle dans des copies séparées de la base de code. Un ingénieur vérifiait l’avancement deux fois par jour et chaque changement proposé faisait l’objet d’une revue.
2. Pourquoi cette migration se prêtait aux agents
Remplacer un système de test est un problème vaste mais souvent répétitif. Les transformations peuvent suivre des motifs : modifier les imports, adapter les helpers, remplacer des sélecteurs, réécrire des assertions et corriger les tests.
Le résultat attendu est fortement vérifiable. Un test doit compiler, s’exécuter et conserver un comportement. Cette boucle fournit à l’agent un retour objectif, contrairement à une refonte métier dont la qualité dépend d’intentions peu documentées.
La migration peut aussi être fractionnée par fichiers, dossiers ou composants. Des lots indépendants limitent les conflits et permettent d’exécuter plusieurs agents en parallèle.
Ces caractéristiques constituent une grille utile : répétitivité, vérifiabilité, partitionnement et faible ambiguïté métier. Plus un chantier les réunit, plus il est adapté à une expérimentation agentique. Cette grille est une lecture méthodologique de Partitech ; l’étude de cas OpenAI ne détaille pas ces transformations une par une.
3. Le rôle décisif du découpage
Donner à un agent “supprime toute la dette technique” produit rarement un résultat exploitable. Il faut construire un inventaire : usages de la dépendance, variantes, exceptions, couverture de tests et ordre de migration.
Le dépôt peut ensuite être découpé en unités comparables. Chaque lot reçoit une instruction concise, des contraintes, une commande de test et une définition de terminé. Les cas atypiques sont isolés au lieu de polluer tous les prompts.
Le retour Asana indique que des instructions plus simples ont mieux fonctionné. Ce constat est cohérent avec une pratique d’ingénierie : déplacer les règles stables vers des scripts, tests et linters, plutôt que d’expliquer tout le projet dans un prompt gigantesque.
4. Le parallélisme contrôlé
Plusieurs agents peuvent accélérer le traitement si leurs périmètres sont indépendants. Des copies séparées du dépôt évitent qu’ils modifient simultanément le même espace de travail.
Il faut néanmoins gérer les dépendances. Un agent peut créer un helper commun dont les autres auraient besoin. Une équipe doit décider quels changements structurants sont intégrés d’abord et quels lots peuvent rester autonomes.
Le parallélisme augmente aussi le volume de revue. Quatre agents produisant des modifications plus vite que l’équipe ne les vérifie créent une nouvelle file d’attente. Le nombre optimal dépend donc de la capacité de CI et de contrôle humain, pas seulement des licences disponibles.
5. Pourquoi les tests restent le véritable accélérateur
La page OpenAI ne documente ni les commandes de test, ni la CI, ni la couverture fonctionnelle de la migration. Les pratiques décrites dans cette section constituent donc notre méthode de sécurisation d’un chantier agentique, et non un résultat mesuré dans le cas Asana.
Un agent peut modifier beaucoup de code ; les tests permettent de savoir rapidement si le changement est acceptable. Sans suite fiable, l’équipe doit lire chaque ligne et reconstruire le comportement attendu, ce qui annule une grande partie du gain.
Avant la migration, stabilisez les commandes de test, réduisez les cas non déterministes et ajoutez des contrôles ciblés. Un test qui échoue une fois sur dix perturbe autant un agent qu’un humain.
La CI doit produire des messages exploitables et permettre des exécutions partielles. L’agent peut corriger plus efficacement lorsqu’il obtient un retour précis sur le fichier, l’assertion ou le type concerné.
6. La revue humaine n’a pas disparu
Le cas publié précise que chaque proposition était revue et approuvée par un humain. L’ingénieur contrôlait le travail deux fois par jour et orientait les agents lorsque la stratégie devait changer.
La revue doit porter sur le comportement, pas seulement sur le style. Vérifiez les suppressions de couverture, les assertions affaiblies, les contournements de type, les snapshots acceptés trop facilement et les modifications de configuration globales.
Un bon agent peut proposer une solution qui fait passer la CI en supprimant le test problématique. Les critères d’acceptation doivent explicitement interdire ce type de raccourci.
7. Ce que le chiffre de coût ne dit pas
Les 12 000 dollars annoncés couvrent les modèles et l’infrastructure, mais la page ne fournit pas de ventilation permettant de savoir comment sont comptés la préparation du dépôt, le développement des outils internes, le temps de revue, l’infrastructure existante, les corrections ultérieures ou la capitalisation de l’équipe.
À l’inverse, la comparaison avec un plan d’au moins cinq ans et environ 6 millions de dollars de personnel repose sur une estimation d’Asana qui n’aurait peut-être jamais été engagée sous cette forme. Les deux chiffres ne sont pas directement comparables sans méthodologie détaillée.
Pour votre projet, calculez le coût complet : modèles, CI, stockage, ingénierie, revue, incidents et maintenance des scripts. Comparez-le à un scénario humain réaliste sur le même périmètre et avec le même niveau de qualité.
8. Une méthode reproductible pour votre projet
Commencez par une analyse statique et un inventaire vérifiable. Choisissez ensuite un lot pilote de 20 à 50 transformations représentatives. Écrivez une instruction courte, une commande de test et une liste d’interdictions.
Faites exécuter le lot par un agent dans une branche isolée. Mesurez le taux d’acceptation sans reprise, le temps de revue, les erreurs fonctionnelles et le coût. Corrigez les outils avant d’augmenter le volume.
Lorsque le pilote est stable, partitionnez le reste du chantier, limitez le nombre d’agents à la capacité de revue et intégrez progressivement. Conservez un tableau de bord : fichiers traités, tests ajoutés, échecs, conflits et dette restante.
Cette méthode complète notre approche de mesure et priorisation de la dette technique et les garde-fous présentés dans Agents de développement en 2026.
9. Les migrations à éviter en premier
N’utilisez pas comme premier pilote une refonte sans tests, une logique métier non documentée ou une migration de données irréversible. Les agents ne compensent pas l’absence de définition du résultat attendu.
Évitez également un chantier où chaque fichier dépend d’une architecture en mouvement. Le conflit entre agents, branches et décisions humaines peut dépasser le gain de génération.
Le cas Asana ne prouve pas qu’un agent remplace une équipe. Il montre, selon le retour publié par OpenAI, qu’une équipe bien outillée peut transformer un chantier répétitif en pipeline de migration parallèle. La compétence clé reste l’ingénierie du système de travail.
Partitech accompagne les migrations techniques assistées par IA : inventaire, conception des lots, prompts et scripts, renforcement des tests, orchestration Codex et contrôle qualité.