Guide d'ingénierie

Faire évoluer la livraison logicielle agent-first

Augmentez la capacité de livraison parallèle utile en améliorant les limites des tâches, le débit de retour et les preuves de mise en production plutôt qu'en ajoutant simplement des agents.

Publié le: 14 juil. 2026
Mis à jour le: 15 juil. 2026
Temps de lecture: 20 min de lecture

Sur cette page

La livraison agent-first consiste à concevoir un workflow de livraison logicielle dans lequel des agents de code réalisent un travail borné d'implémentation ou d'investigation sous contrôles d'ingénierie. Cela ne signifie pas que chaque ticket est autonome, que chaque agent peut fusionner ou que le parallélisme est automatiquement productif. La capacité limitante est souvent le débit de CI, la contention sur les fichiers les plus sollicités, la qualité de l'évaluation ou l'attention des examinateurs, plutôt que la disponibilité des modèles — la même discipline qu'une couche d'orchestration edge managée comme Optimi applique lorsqu'elle admet du trafic chez plusieurs fournisseurs selon une capacité mesurée, et non au mieux.

L'article d'OpenAI de février 2026 sur le harness engineering souligne l'environnement autour des agents de code. Les travaux d'Anthropic sur les agents de longue durée et parallèles démontrent un point connexe : les agents peuvent progresser durablement lorsque les tâches, les retours, l'état et la synchronisation sont explicites. Ce sont des préoccupations de système de livraison qui nécessitent une planification de capacité, pas seulement de meilleurs prompts.

Modéliser la livraison agent-first à l'échelle comme un budget de capacité partagé

Ajouter des agents n'augmente pas le débit dès qu'une autre étape est saturée. Prenons Acme Shop, une enseigne e-commerce dont le service checkout-api reçoit un flux constant de tâches ouvertes par des agents de code. Sa politique expose quatre réservoirs de capacité indépendants : le verrou de revendication par chemin de fichier, les exécutions d'agents actives, les emplacements CI disponibles et les emplacements de revue humaine. Le débit réel est fixé par celui de ces réservoirs qui se remplit le premier : faire passer les exécutions d'agents de quatre à douze sans toucher aux emplacements CI ni de revue ne fait qu'allonger la file devant les mêmes goulots d'étranglement. La loi de Little offre le contrôle sous-jacent — les tâches en vol égalent le taux d'arrivée multiplié par le temps moyen dans le système — donc mesurez où les tâches attendent réellement, puis n'augmentez que le réservoir qui présente une marge constatée, un incrément à la fois.

Commencer par une taxonomie de livraison

Classez le travail avant de le paralléliser. De bons premiers candidats sont les correctifs étroits avec reproduction déterministe, les ajouts de tests, les mises à jour de dépendances avec des barrières de compatibilité connues, la documentation synchronisée au code ou les investigations de dépôt qui produisent des preuves plutôt que des écritures. De mauvais premiers candidats comprennent les changements produit ambigus, les migrations transverses étendues, les incidents de production, les changements sensibles à la sécurité sans vérificateur fort et les tâches partageant un petit nombre de fichiers très sollicités.

Pour chaque catégorie, documentez l'autonomie maximale, la validation requise, l'examen humain attendu, la stratégie de restauration ainsi que le budget de coût et de latence. Un nettoyage de test à faible risque peut suivre une politique différente d'une migration de base de données, même si les deux tiennent dans une pull request.

Décomposer pour une progression indépendante

Les agents parallèles ont besoin d'unités de travail indépendantes. Découpez par service, package, échec de test, feature flag ou frontière de contrat, et non par lignes de code arbitraires. Chaque tranche nécessite un responsable, des fichiers attendus, des critères d'acceptation et une déclaration de dépendances. Chez Acme Shop, la tâche ACME-1842, qui ajoute une validation du pays manquant dans checkout-api, illustre une bonne tranche : indépendante, testable et cantonnée à un chemin de fichier précis. Un second agent peut y ajouter en parallèle un test de délai d'expiration pour le fournisseur de taxes, car il touche une couture différente ; mais aucun des deux ne doit modifier le contrat partagé du panier sans qu'une tâche de conception préalable et un responsable unique n'aient tranché — sinon les deux progressent sur la même interface sans le savoir, et deux revues individuellement vertes peuvent masquer une incompatibilité entre elles.

Utilisez une légère revendication de tâche ou une file avec des baux afin que les agents ne se concurrencent pas sur le même changement — chez Acme Shop, un bail type dure trente minutes et limite à une seule exécution active par chemin de fichier. Faites expirer les revendications abandonnées et consignez pourquoi le travail s'est arrêté ; les travaux d'Anthropic sur les agents parallèles décrivent une synchronisation explicite des tâches et des espaces de travail séparés, à garder assez simple pour rester auditable.

Ne transformez pas une grande migration en dizaines de prompts concurrents. Créez d'abord une jointure vérifiée : un adaptateur, un test de compatibilité, un contrat d'interface ou un déploiement progressif. Le travail parallèle devient plus sûr après que le système expose des preuves indépendantes. Enfin, la revendication de tâche coordonne le travail ; elle n'est pas une autorité de fusion. Ce sont les protections du dépôt, les vérifications obligatoires et l'approbation de déploiement qui imposent la limite, pas le texte d'un prompt.

Concevoir le débit CI et la capacité de revue ensemble

La vitesse des agents est limitée par la boucle de retour complète, pas seulement par l'inférence du modèle. Instrumentez le temps d'attente CI, le provisionnement, l'installation des dépendances, les tests ciblés puis faisant autorité, le téléversement des artefacts, le taux de réexécution et l'attente des examinateurs. Une tâche de modèle de dix minutes qui attend quarante minutes un exécuteur n'est pas un parcours de livraison rapide. Plus important encore : produire des pull requests prêtes à examiner plus vite que les responsables ne peuvent les évaluer augmente le risque au lieu de le réduire.

Augmentez la capacité sans affaiblir les barrières :

Exécutez des vérifications ciblées et déterministes pour le package affecté avant les suites coûteuses.
Répartissez les tests indépendants et n'utilisez l'exécution sélective que si l'analyse des dépendances est fiable.
Mettez en cache les dépendances immuables par fichier de verrouillage et plateforme, non les espaces de travail ni les identifiants mutables.
Préconstruisez les images d'exécuteur communes et ne préchauffez que des artefacts sûrs, vérifiés pour leur intégrité.
Donnez aux agents des quotas de concurrence explicites pour qu'ils ne privent pas les charges de travail humaines ou de release de ressources.
Mettez les tests instables en quarantaine avec un responsable et une date d'expiration ; ne les réessayez pas silencieusement jusqu'à ce qu'ils passent.

La barrière de fusion qui fait autorité doit rester reproductible dans un environnement propre. Des pré-vérifications plus rapides servent à réduire le temps d'itération, pas à prouver que la barrière complète est inutile. Pour ACME-1842, un test ciblé de type « test:checkout -- tax » donne un retour en quelques secondes, tandis que la barrière propre ci:checkout et la revue du responsable décident seules de l'acceptation.

La preuve de capacité doit vivre sur une seule ligne de temps

Le temps de file, la télémétrie CI et l'attente des examinateurs vivent souvent dans trois outils séparés, ce qui reste supportable jusqu'à ce qu'une release cale et ressemble à trois tableaux de bord sans rapport. Le même écart de corrélation apparaît sur tout parc combinant plusieurs fournisseurs derrière un point d'entrée unique ; une couche de supervision comme MYO chez Optimi réunit cette télémétrie dans une seule ligne de temps, afin qu'une pénurie de capacité CI et un arriéré de revue se lisent comme un seul événement attribuable.

La capacité de revue devient souvent la contrainte la plus étroite dès que la mise à l'échelle des agents de code s'accélère : les agents ouvrent des pull requests plus vite que les responsables ne peuvent les évaluer. Exigez que chaque pull request d'agent porte un court résumé de preuve — périmètre touché, vérifications exécutées, décisions à inspecter en priorité — pour que le temps de revue serve au jugement plutôt qu'à reconstituer le contexte. Routez aussi selon la catégorie : un changement de contrat partagé exige l'ingénieur responsable, tandis qu'un ajout étroit comme le test d'ACME-1842 peut recevoir un passage plus léger. Suivez le taux de rebond des examinateurs ; une hausse signale une dette de revue à résoudre en ralentissant l'admission, non en ajoutant des examinateurs qui valident sans regarder.

Regrouper les tâches sans saturer la capacité CI pour agents

Une fois que les emplacements CI deviennent le goulot d'étranglement mesuré, dépensez mieux la capacité CI pour agents existante avant d'ajouter des exécuteurs. Les systèmes de file de fusion — la merge queue de GitHub, ou le modèle plus ancien de gating façon Zuul chez OpenStack et Google — combinent plusieurs changements indépendants déjà en file dans une branche temporaire unique, exécutent la CI une seule fois sur ce lot, et ne paient un cycle de bisection plus coûteux que si le lot échoue.

Appliqué aux deux emplacements CI d'Acme Shop : regroupez trois tâches checkout indépendantes et cantonnées à des chemins distincts en une seule passe combinée plutôt que trois passes séquentielles, et scindez-bisectez en cas d'échec plutôt que de rejeter les trois. Le regroupement n'aide que si les changements sont réellement indépendants — une tâche de contrat partagé non résolue, comme le schéma de panier, réintroduit la contention qu'une revendication cantonnée par chemin visait à empêcher, et doit rester hors de tout lot. Le compromis : un peu de latence de fusion contre un débit sensiblement supérieur pour une capacité CI de taille fixe.

Budgéter latence, coût et contexte

Définissez un budget par catégorie de tâche pour l'attente en file, le temps d'exécution, l'inférence du modèle, les appels d'outils, les tokens, les minutes CI, les tentatives et l'attente de revue. Suivez p50 et p95, car une moyenne saine peut masquer un arriéré de travail bloqué. Ajoutez aussi des budgets de contexte : limitez la sortie de recherche dans le dépôt, interdisez les journaux sans limite et utilisez une récupération ciblée afin que les agents conservent les critères d'acceptation et les échecs récents.

Utilisez une politique d'arrêt et d'escalade lorsqu'une exécution dépasse le budget sans produire de nouvelles preuves déterministes. Conservez la branche, le diff, la sortie des tests et la classification du blocage. Un opérateur peut alors décider de découper la tâche, d'ajouter une fixture manquante, d'augmenter la capacité mesurée ou de rejeter l'approche — jamais d'augmenter silencieusement la concurrence, de réessayer un test instable indéfiniment, ou de contourner la revue pour vider une file en retard.

L'attribution des coûts doit inclure toute la boucle : dépense de modèle, temps d'exécuteur, stockage, réseau, tentatives, appels d'évaluateur et examen humain. L'exécution d'agent la moins chère n'est pas nécessairement le changement livré au plus faible coût si elle crée un long examen ou une régression.

Garder les contrôles de fusion et de release indépendants

Un agent peut préparer une pull request, mais les protections du dépôt doivent imposer indépendamment les examens, vérifications, exigences de signature ou de provenance et approbations de déploiement. Séparez l'autorisation d'écriture de branche de l'autorisation de fusion, et l'autorisation de fusion de l'autorité de déploiement en production. Assurez-vous que chaque chemin d'automatisation dispose d'une procédure de restauration et d'un responsable de service redevable.

Utilisez canaris, feature flags, livraison progressive et supervision au niveau du service pour les changements susceptibles d'affecter le comportement à l'exécution. Ce sont des contrôles d'ingénierie normaux, non des concessions spéciales aux agents. Un changement généré par modèle doit recevoir le même niveau d'examen, voire un niveau supérieur, que tout autre changement selon son rayon d'impact.

Valider le comportement de mise à l'échelle et récupérer

Validez la mise à l'échelle comme n'importe quel autre comportement système, avec des cas positifs, négatifs et de défaillance. En positif, deux tâches checkout indépendantes obtiennent des revendications distinctes, des espaces de travail séparés, passent leurs vérifications ciblées, puis reçoivent des emplacements de CI et de revue sans jamais toucher aux mêmes fichiers. En négatif, une deuxième revendication sur le chemin d'ACME-1842 est refusée ou mise en file, une cinquième exécution attend lorsque le quota d'agents actifs est de quatre, et un agent ne peut jamais fusionner au seul motif que sa revendication a réussi. En défaillance, simulez un exécuteur bloqué ou un bail expiré : l'exécution est marquée bloquée, les artefacts conservés, et la tâche ne revient en file qu'après qu'un responsable a décidé de la renouveler, de la scinder ou de l'annuler.

La récupération commence toujours par la ressource limitante : réparez le provisionnement CI, réassignez le responsable ou réduisez le chevauchement des tâches avant d'ajouter des agents, et si le titulaire d'une revendication disparaît, faites expirer le bail avec une trace d'audit plutôt que de laisser un autre agent écraser une branche partielle inconnue. Des correctifs de checkout dupliqués trahissent presque toujours une revendication cantonnée par chemin manquante ; une file CI qui domine la latence perçue trahit une saturation d'exécuteurs à combler par de la capacité constatée, pas par des barrières assouplies ; et un lot regroupé qui échoue sans responsable évident doit être scindé et rejoué par moitié pour isoler le changement fautif.

Le risque de cohérence est un quatrième mode de défaillance à valider délibérément. Des passes de CI indépendantes et des revues individuellement réussies ne garantissent pas des conceptions compatibles : deux agents peuvent chacun ajouter un mécanisme de nouvelle tentative différent pour le même appel au fournisseur de taxes, et passer chacun leur revue sans jamais se voir l'un l'autre. Exécutez une analyse périodique de détection de symboles dupliqués, distincte de la CI par pull request, et confiez à un responsable unique la consolidation avant que les implémentations ne divergent davantage.

Envisager l'architecture de performance du parcours de livraison lorsqu'elle est un goulot d'étranglement

L'architecture de performance edge et de livraison peut être pertinente lorsque des équipes mondialement distribuées ou des exécuteurs CI éphémères récupèrent de grosses dépendances, archives source, images conteneur et artefacts de build. Un cache proche, un routage fiable et une distribution protégée des artefacts peuvent améliorer la latence entre file CI et retour. C'est facultatif : cela n'aide qu'après que le profilage a montré que la latence du parcours de livraison ou la disponibilité des artefacts est significative. Cela ne remplace ni la conception des tâches, ni le cache sécurisé, ni le parallélisme des tests, ni des exécuteurs fiables.

Mesurer le débit utile

Suivez les changements acceptés, sans régression, par unité de capacité contrainte, et non les pull requests générées. Les métriques utiles comprennent le temps entre file et premier retour, le délai jusqu'au correctif validé, l'utilisation de CI par catégorie de tâche, le taux de conflits de fusion, les raisons des échecs de validation, les reprises des examinateurs, les défauts échappés, le taux de restauration et le coût par changement accepté.

Segmentez les résultats par dépôt, type de tâche, version de l'environnement, modèle, permissions des outils et version de l'évaluateur. Une politique qui fonctionne pour les mises à jour de documentation peut être dangereuse pour les changements d'infrastructure. Utilisez ces preuves pour élargir ou restreindre délibérément l'autonomie.

Liste de contrôle de mise à l'échelle

Classez les types de tâches et définissez leurs limites de validation, d'autonomie et de restauration.
Divisez le travail selon des frontières testables indépendamment et coordonnez explicitement les interfaces partagées.
Isolez branches et espaces de travail ; utilisez des revendications de tâches pour éviter les efforts en double.
Instrumentez les temps de file CI, provisionnement, test et réexécution avant d'ajouter de la concurrence d'agents.
Gardez les pré-vérifications ciblées rapides et préservez une barrière de fusion propre et reproductible.
Bornez la capacité de modèle, d'exécuteur, de contexte, de tentative et d'examen pour chaque catégorie de tâche.
Regroupez les changements indépendants dans la CI quand les exécuteurs sont la contrainte mesurée, et bisectez plutôt que de rejeter un lot en échec.
Exigez un résumé de preuve par pull request d'agent et suivez le taux de rebond des examinateurs.
Validez avec des cas positifs, négatifs et de défaillance, plus une analyse périodique de cohérence contre les doublons de logique.
N'utilisez l'optimisation du parcours de livraison que lorsque les mesures montrent qu'elle est un goulot d'étranglement CI significatif.

Références faisant autorité

Étendez la discipline de capacité jusqu'au chemin de livraison lui-même

Miroirs de dépendances, registres d'artefacts et trafic sortant des exécuteurs CI traversent tous un réseau avant qu'une fusion n'aboutisse. Optimi orchestre ce réseau pour la Performance, la Sécurité et la Visibilité sur l'ensemble des fournisseurs, avec MYO pour corréler les preuves — afin qu'une revue de capacité CI ne s'arrête pas à l'exécuteur.

Discuter de la visibilité du chemin de livraison avec Optimi