Le génie agentique en cinq niveaux : des spécifications et des agents parallèles aux règles et au contrôle.
Karpathy a qualifié ce changement de codage axé sur l’ambiance. Découvrez les cinq niveaux du génie agentique : spécifications, orchestration, règles codifiées, révision humaine et observabilité, ainsi qu’un plan hebdomadaire.
Le codage par ambiance a connu un grand succès. Andrej Karpathy, celui qui a inventé ce terme, a depuis déclaré que cette ère était révolue. Il ne s’est pas contenté de nommer le problème : il a esquissé ce qui peut le remplacer, à savoir l’ingénierie agente, où des agents d’intelligence artificielle planifient, écrivent, testent et déploient du code, tandis qu’un humain assure une supervision structurée. L’humain définit l’intention, les agents la mettent en œuvre, et l’humain vérifie le résultat. Il s’agit d’une méthode professionnelle pour développer avec l’intelligence artificielle et non simplement à ses côtés, et elle est bien loin de la simple incitation occasionnelle suivie d’espoir.
Une tentative antérieure de mise en place d’un développement piloté par des spécifications, c’est-à-dire d’écrire à l’avance ce qu’un système doit faire avant que tout agent ne génère quoi que ce soit, ne couvre en réalité qu’un seul niveau de cette discipline. Depuis, les équipes en production en ont ajouté quatre autres. Ce qui suit décrit l’ensemble des cinq niveaux, montre à quoi ressemble chacun en pratique, et se termine par un plan d’exercices d’une semaine pour commencer.
Pourquoi le nom est important
Ce label va au-delà d’une simple marque. Il marque la frontière entre deux manières de travailler très différentes, et Karpathy a tracé cette frontière à l’aide de deux questions. Le codage par ambiance se demande si quelque chose peut fonctionner. L’ingénierie agente se demande si cela peut fonctionner de manière fiable, à grande échelle, sans introduire de vulnérabilités.
La première question abaisse les barrières. N’importe qui peut maintenant créer un prototype : un développeur amateur décrit ce qu’il souhaite, accepte les résultats obtenus et finit par disposer d’une démonstration fonctionnelle. C’est une approche vraiment utile pour l’exploration. La deuxième question, quant à elle, établit des limites. Les logiciels qui traitent les paiements, gèrent des données de santé ou gèrent des infrastructures exigent toujours une discipline professionnelle. L’agent peut écrire le code, mais c’est un être humain qui doit concevoir le système, en définir les limites et vérifier les résultats.
Les propres mots de Karpathy étaient directs : l’ingénierie d’agents est une discipline d’ingénierie, et les agents sont imprévisibles, stochastiques et extrêmement puissants ; donc le véritable problème réside dans leur coordination afin qu’ils avancent plus rapidement sans nuire à la qualité. Ce problème, celui de la vitesse sans compromis sur la qualité, est désormais la question centrale du domaine. Ce n’est pas seulement son avis. IBM, Forrester et Anthropic ont chacun publié des cadres formels pour une nouvelle discipline distincte au cours du même trimestre, en arrivant à cette conclusion de manière indépendante. Lorsque des organisations qui ne s’accordent que rarement convergent au même moment, l’idée a de la substance.
Le terme a persisté parce que les ingénieurs avaient besoin d’un mot pour décrire le travail qu’ils effectuaient déjà : plus structuré que la simple demande, plus discipliné que le coding par intuition, et pourtant différent du développement traditionnel. La discipline ainsi désignée comporte cinq niveaux, chacun reposant sur celui qui le précède. En omettre un seul rend tout ce qui se trouve au-dessus peu fiable.
Niveau 1 : spécification
Rédigez la spécification avant que tout agent ne génère de code. Décrivez ce que le système doit toujours faire, ce qu’il ne doit jamais faire, comment savoir s’il fonctionne et comment savoir s’il s’est arrêté. Placez tout cela dans un seul document, maintenez ce document à jour, et évaluez tout ce que l’agent construit en fonction de celui-ci.
Dans l’ingénierie de l’IA, différentes approches appellent cela la planification stratégique, la définition de l’intention ou simplement la spécification. Le nom varie, mais la pratique reste la même : savoir ce qui est souhaité avant de demander à un agent de le créer.
Un point est facile à négliger. Une spécification n’est pas un document créé le jour du lancement ; c’est un document vivant. Chaque fois que la mise en œuvre révèle quelque chose que la spécification n’avait pas prévu – et c’est inévitable –, celle-ci est mise à jour. Les équipes dont les membres s’éloignent progressivement de l’intention initiale sont presque toujours celles qui ont rédigé la spécification dès le premier jour sans jamais y revenir.
Un modèle minimal commence par une en-tête indiquant que ce document constitue la source de vérité :
# Feature Spec: [Feature Name]
## Last updated: [Date] — this document is the source of truth
Viennent ensuite les listes de contrôle du comportement, une section décrivant les comportements requis et une autre indiquant les limites strictes, comme l’interdiction de traiter un remboursement supérieur à 500 $ sans approbation humaine :
## What this must always do
- [ ] [Behaviour 1 — specific, testable]
- [ ] [Behaviour 2 — specific, testable]## What this must never do
- [ ] [Boundary 1 — e.g. "Never process refund >$500 without human approval"]
- [ ] [Boundary 2 — e.g. "Never fabricate a citation"]## Success criteria (measurable)
- Context recall: >0.85
- Faithfulness: >0.90
- Cost per query: <$0.15
- Latency p95: <2s## Failure signals (alert if breached)
- Any metric drops >5% from 7-day baseline
- Cost per task exceeds 3x expected range
- User complaint rate exceeds 2% of sessions## Decomposition (for parallel agents)
- [ ] Task A: [scope] — can be delegated independently
- [ ] Task B: [scope] — depends on Task A output
- [ ] Task C: [scope] — can run parallel with Task A
Restez sur une seule page. Si la spécification devient trop longue, la fonctionnalité est trop volumineuse et doit être divisée jusqu’à ce que chaque partie tienne sur une page.
Même une spécification parfaite remise à un seul agent rencontre des limites de productivité, c’est pourquoi il existe une deuxième couche.
Couche 2 : orchestration
Prenons l’exemple d’une fonctionnalité qui concerne le schéma de la base de données, l’API, l’interface utilisateur et le jeu de tests. Traditionnellement, un ingénieur travaille sur chaque élément à tour de rôle, ou une équipe coordonne ses efforts au cours d’un sprint. Dans l’ingénierie agentic, quatre agents s’occupent simultanément des quatre éléments : l’un écrit la migration, un autre les points d’entrée, un troisième les composants de l’interface utilisateur, et le quatrième écrit les tests tout en vérifiant le reste pour détecter d’éventuels problèmes de sécurité. Chacun dispose de son propre contexte et de ses propres contraintes, et leurs résultats sont fusionnés en une modification cohérente.
Cela n’est pas hypothétique. Stripe utilise ce modèle en production, avec un système d’agents internes qui génère plus de 1 000 demandes de fusion par semaine, chacune rédigée par un agent, examinée par une personne, validée par les tests d’intégration et mise en production. L’amélioration obtenue est d’un ordre de grandeur, et non simplement un facteur deux.
Le rythme est un cycle qui se répète pour chaque fonctionnalité : planifier, exécuter, vérifier. Certaines équipes l’appellent le cycle PEV.
- Planifier. Le humain rédige la spécification à partir du niveau 1 et divise le travail en unités pouvant être déléguées indépendamment. Une décision cruciale consiste à déterminer quelles tâches peuvent être exécutées en parallèle puisqu’elles ne dépendent pas des résultats des autres, et lesquelles doivent être exécutées dans l’ordre.
Ce qui prenait auparavant deux semaines devient une session de travail ciblée d’une ou plusieurs heures, voire d’un jour. L’effort humain se concentre principalement sur la planification et la vérification, tandis que les agents s’occupent du travail intensif entre ces deux étapes.
Il faut du temps pour assimiler une nuance : l’objectif est un parallélisme utile, et non un parallélisme maximal. Trois agents sur des modules étroitement couplés génèrent des conflits dont la résolution coûte plus que l’économie obtenue grâce au fonctionnement en parallèle. Deux agents sur des modules indépendants, avec un troisième qui supervise les deux, produisent un résultat cohérent. L’art réside dans la décomposition, en divisant le travail de manière à pouvoir le déléguer sans avoir de problèmes d’intégration par la suite.
Un orchestrateur de base peut décrire la boucle dans sa docstring :
class AgenticOrchestrator:
"""Plan → Execute (parallel) → Verify"""
et mettre en œuvre l’étape de planification, qui divise une fonctionnalité en tâches déléguables :
def plan(self, feature_spec: dict) -> dict:
"""Decompose feature into independently delegatable tasks."""
tasks = []
for component in feature_spec["decomposition"]:
tasks.append({
"id": component["id"],
"spec": component["scope"],
"constraints": feature_spec["must_never"] + component.get("local_rules", []),
"depends_on": component.get("depends_on", []),
"verification": component.get("success_criteria", []),
})
independent = [t for t in tasks if not t["depends_on"]]
sequential = [t for t in tasks if t["depends_on"]]
return {"parallel": independent, "sequential": sequential} async def execute(self, plan: dict):
"""Run independent tasks in parallel, sequential tasks in order."""
parallel_results = await asyncio.gather(*[
self.delegate_to_agent(task) for task in plan["parallel"]
])
for task in plan["sequential"]:
result = await self.delegate_to_agent(task, prior=parallel_results)
parallel_results.append(result)
return parallel_results def verify(self, results: list, spec: dict) -> dict:
"""Check all outputs against the spec — structural, not line-by-line."""
issues = []
for result in results:
if not self.satisfies_spec(result, spec):
issues.append(f"{result['id']}: does not satisfy spec")
if self.conflicts_with(result, results):
issues.append(f"{result['id']}: conflicts with another module")
return {"passed": len(issues) == 0, "issues": issues}
Le principe directeur est un ciblage strict du contexte. Chaque agent ne doit recevoir que sa section de spécifications, ses fichiers de code et ses règles. Intégrer l’ensemble du codebase dans chaque fenêtre de contexte gaspille des tokens, augmente les coûts et affaiblit l’attention du modèle.
L’orchestration améliore le débit de traitement, mais un débit sans cohérence engendre le chaos. Chaque agent doit connaître les conventions de l’équipe, les contraintes architecturales et les politiques de sécurité, ainsi que les spécifications relatives à sa propre tâche. La couche suivante fournit ces informations.
Couche 3 : règles codifiées
La plupart des outils disposent déjà d’une version de cela. Claude Code charge un fichier CLAUDE.md au début de chaque session, Cursor lit .cursorrules et Codex lit AGENTS.md. Le concept est identique : un fichier situé dans la racine du projet qui indique à l’agent comment se comporter.
En 2026, les équipes sont allées plus loin en codant toute leur culture de développement sous forme de contraintes lisible par les agents, au-delà du simple ensemble technologique. Des professionnels tels que Paul Duvall documentent les modèles émergents des équipes en production, et InfoQ suit leur niveau de maturité. Quatre modèles se retrouvent partout où l’ingénierie agente est utilisée :
- Développement piloté par des spécifications, où les spécifications guident le travail (Niveau 1).
- Règles codifiées et contraintes architecturales : conventions, politiques de sécurité, modèles de gestion des erreurs, normes de nommage et procédures de déploiement, tous stockés dans des fichiers que les agents chargent avant de démarrer.
- Décomposition atomique avec des agents parallèles : les fonctionnalités sont divisées en les plus petits éléments possibles pouvant être traités indépendamment (Niveau 2).
C’est à l’échelle que la plupart des équipes rencontrent des difficultés. Un CLAUDE.md fonctionne bien pour un prototype de 1 000 lignes. Une base de code de 100 000 lignes ne peut pas être décrite dans un seul fichier, et même si c’était possible, les règles rempliraient la fenêtre de contexte avant que l’agent n’atteigne la tâche réelle.
Les équipes qui résolvent ce problème construisent des systèmes de règles hiérarchiques, tout comme les configurations ESLint héritent de préférences organisationnelles et peuvent être modifiées pour chaque projet. La structure des dossiers est la suivante :
your-company/
├── .ai-rules/
│ └── org-rules.md ← Company-wide: security, compliance, style
│
├── team-payments/
│ ├── .ai-rules/
│ │ └── team-rules.md ← Team-level: error handling, testing, deploys
│ │
│ ├── service-checkout/
│ │ ├── CLAUDE.md ← Repo-level: architecture, tech stack, builds
│ │ ├── src/
│ │ │ ├── auth/
│ │ │ │ └── .ai-rules.md ← Module: auth-specific constraints
│ │ │ └── payments/
│ │ │ └── .ai-rules.md ← Module: PCI compliance rules
En haut se trouve le fichier d’organisation, chargé pour chaque agent dans chaque répertoire. Il couvre des aspects tels que l’interdiction d’envoyer des secrets, l’exigence d’authentification pour les API publiques, ainsi que l’interdiction de divulguer des traces d’exécution dans les réponses d’erreur :
# org-rules.md (loaded for every agent, every repo)
- Never commit secrets or credentials
- All public APIs require authentication
- Error responses must never expose stack traces
- Log every state-changing operation with user context
Sous celui-ci, un fichier d’équipe hérite de ces règles et en ajoute ses propres, comme le modèle de résultat au lieu d’exceptions levées, tout accès à la base de données via une couche de repository, ainsi que des tests couvrant le scénario réussi et au moins deux modes d’échec :
# team-rules.md (inherits org, adds team specifics)
- Use Result<T, E> pattern — never throw exceptions
- All database queries go through the repository layer
- Tests must cover the happy path + 2 failure modes minimum# CLAUDE.md (inherits team, adds repo specifics)
- This repo uses Express.js + Prisma + PostgreSQL
- Run `npm test` before suggesting any PR is ready
- Migrations are append-only — never modify applied migrations# module .ai-rules.md (inherits repo, adds module specifics)
- auth/: All token operations must use constant-time comparison
- payments/: PCI DSS requires field-level encryption on card data
Un agent charge les règles de l’organisation, les règles de l’équipe, le fichier CLAUDE.md du répertoire ainsi que les règles relatives au module qu’il traite. Cela permet de garder le contexte ciblé et simplifié. L’agent chargé du module des paiements reçoit les règles de conformité PCI, tandis que l’agent chargé du frontend ne les reçoit pas, car ces règles consommeraient inutilement des ressources de contexte.
Les règles indiquent comment travailler, mais l’interprétation finale nécessite néanmoins un jugement humain. Un code peut respecter toutes les conventions tout en étant architecturalement incorrect, résolvant ainsi le problème soulevé de manière à en créer un plus grave ailleurs. C’est pourquoi la couche suivante n’est pas optionnelle.
Couche 4 : supervision humaine
Trois mots décrivent le modèle de fonctionnement qui en est résulté : déléguer, examiner, assumer la responsabilité.
Déléguer. Donnez à l’agent une tâche bien définie avec des contraintes claires et laissez-le travailler. Ne microgérez pas la mise en œuvre ni ne surveillez ses frappes au clavier. Les spécifications et les règles existent pour que l’on puisse faire confiance à l’agent pour les suivre.
Vérifier. Traitez le résultat retourné comme une demande de fusion provenant d’un ingénieur compétent mais junior : rapide, compétent, mais susceptible de commettre des erreurs subtiles que seul quelqu’un qui comprend le système dans son ensemble pourrait détecter. Vérifiez l’adéquation architecturale et les cas limites. Confirmez que les spécifications ont été respectées, ce qui signifie que l’intention initiale a été atteinte et non simplement que les tests passent.
Assumer la responsabilité. C’est l’humain qui est responsable de la qualité finale. L’agent a effectué le travail, la personne a donné son accord, et toute panne en production relève de sa responsabilité. Cette prise en charge distincte distingue l’ingénierie par agents du codage informel, où personne ne prend en charge le résultat final.
Le goulot d’étranglement est réel. Les agents génèrent du code plus rapidement que les humains ne peuvent le vérifier, et la tentation est de relâcher les exigences de rigueur pour rester à jour. C’est précisément cette tentation qui a permis au coding vibe de s’imposer : les développeurs acceptaient le résultat car il semblait correct, passait les tests et la date limite approchait. L’ingénierie agente existe pour empêcher ce schéma de se reproduire.
Le rapport sur les tendances du codage agentiel d’Anthropic décrit comment les ingénieurs expérimentés gèrent cette situation. Ils délèguent les tâches dont la correction peut être vérifiée en un coup d’œil ou dont les enjeux sont faibles. Plus une tâche est conceptuellement complexe ou dépendante de la conception, plus il est probable qu’ils la conservent ou la résolvent ensemble avec l’agent. Savoir quoi déléguer et quoi garder pour soi constitue la nouvelle compétence essentielle. Elle s’améliore avec la pratique, aucun cadre ou outil ne peut la remplacer, et elle distingue l’ingénieur qui utilise efficacement les agents de celui qui produit des résultats impressionnants mais qui s’effondrent sous l’examen minutieux.
Une liste de contrôle avant déploiement aide à s’assurer que tout ce qui est généré par un agent est prêt pour la production. Son intitulé est :
## Agent Output Review Checklist
et son corps, organisé en sections commençant par l’alignement des spécifications (tous les comportements requis sont-ils implémentés, les limites sont-elles respectées, les critères de succès sont-ils remplis) puis poursuivant avec l’architecture et la pertinence commerciale :
### Spec alignment (does it do what was asked?)
- [ ] All "must always do" behaviours are implemented
- [ ] No "must never do" boundaries are violated
- [ ] Success criteria from the spec are met or tested### Architectural coherence (does it fit the system?)
- [ ] No new dependencies introduced without justification
- [ ] Consistent with naming, patterns, and structure of existing code
- [ ] No duplication of logic that exists elsewhere### Safety and edge cases
- [ ] Error handling covers the failure modes the spec anticipated
- [ ] No hardcoded credentials, keys, or environment-specific values
- [ ] Input validation present on all external-facing boundaries### What the agent cannot check for itself
- [ ] Does this make business sense? (not just technical correctness)
Vaut la peine de l’imprimer et de le coller près de l’écran. Les outils de linting et les systèmes CI peuvent automatiser en partie les trois premières sections. La dernière, le sens commercial, est la raison pour laquelle un être humain reste impliqué dans le processus.
Les revues permettent de détecter des problèmes avant la publication. Une dégradation lente de la qualité, des regressions subtiles et une augmentation des coûts que personne ne remarque avant l’arrivée de la facture ne se manifestent qu’après, et c’est là que l’intervention humaine devient nécessaire.
Niveau 5 : développement observable
Le monitoring et le développement observable ont des noms similaires mais remplissent des fonctions différentes. Le monitoring indique que le système est opérationnel, avec une latence normale, peu d’erreurs et un tableau de bord vert. Le développement observable précise ce que le système a fait : quel agent a géré quelle tâche, selon quelle spécification, avec quels outils, en produisant quel code, et si le résultat correspondait à l’objectif visé.
La différence apparaît à 2 heures du matin. Avec une simple surveillance, on sait qu’il y a un problème mais on ignore en quoi il consiste, ce qui oblige à passer la nuit à examiner les différences et à deviner quels modules sont en cause. Avec un développement observable, le suivi de la déploiement montre que l’agent 3 a modifié le flux d’authentification par rapport à une spécification qui ignorait les mises à jour simultanées des tokens. Cela représente douze minutes de débogage ciblé au lieu de deux heures de spéculations.
En pratique, cela revient à trois habitudes :
- Chaque tâche effectuée par un agent génère un suivi structuré : la spécification reçue, les outils utilisés, les fichiers modifiés, la version du modèle, les tokens consommés et le résultat de la vérification. Lorsqu’un bug apparaît trois jours plus tard, ce suivi indique ce qui s’est passé, sans que personne n’ait besoin de se souvenir.
Une configuration minimale commence par des importations pour enregistrer une petite trace :
from dataclasses import dataclass, field
from datetime import datetime
et la classe de données trace appliquée à chaque tâche déléguée :
@dataclass
class AgentTrace:
"""Minimum trace for every agent-delegated task."""
task_id: str
agent_id: str
spec_given: str # What was the agent told to do?
tools_used: list[str] # Which tools did it invoke?
files_modified: list[str] # What did it change?
model_version: str # Which model, which version?
tokens_consumed: int # What did it cost?
started_at: datetime = field(default_factory=datetime.utcnow)
completed_at: datetime | None = None
verification_result: str = "" # pass / fail / needs_review
human_reviewer: str = "" # Who signed off?
issues_found: list[str] = field(default_factory=list)
Ajoutez une revue hebdomadaire de quinze minutes. Son intitulé :
## Weekly Observable Development Review (15 minutes)
et ses questions : combien de tâches ont été déléguées, combien ont passé la vérification dès la première tentative (objectif supérieur à 80 %), quelle catégorie présentait le plus de problèmes, et quels étaient les trois principaux problèmes :
1. How many agent tasks were delegated this week? ___
2. How many passed verification on first attempt? ___ (target: >80%)
3. Which task category had the most issues? ___
4. Top 3 issues found during review:
- ___
- ___
- ___
5. Which issues should become codified rules (Layer 3)? ___→ Update CLAUDE.md with any new rules from this week's observations.
Quinze minutes par semaine suffisent pour boucler le cycle. Les observations deviennent des règles, les règles améliorent l’orchestration, une meilleure orchestration produit de meilleurs résultats, et ces résultats génèrent de nouvelles observations.
Des preuves que cela fonctionne
Deux chiffres se détachent. Plus de 1 000 demandes de fusion par semaine sur Stripe sont rédigées par des agents, revues par des humains, validées par les systèmes CI et mises en production – il ne s’agit pas d’une expérience en environnement de test. C’est un volume de travail qui était impossible il y a un an. Un autre public cite des chiffres différents : l’enquête de McKinsey indique des réductions des coûts d’exploitation de 20 à 40 pour cent, un chiffre qui permet de faire passer l’IA d’une initiative d’innovation à une infrastructure opérationnelle, ce que demande le directeur financier et pas seulement le directeur technique.
Quelles en sont les conséquences pour une carrière en ingénierie
Le rôle des ingénieurs évolue sans disparaître. En 2026, ils écrivent moins de code fondamental et consacrent plus de temps à orchestrer des agents, à concevoir l’architecture, à définir des objectifs et des contraintes, ainsi qu’à vérifier les résultats. La compétence clé passe de la syntaxe à la pensée systémique, en passant de la question de savoir comment écrire une fonction à celle de savoir comment concevoir un système dans lequel les agents peuvent l’écrire correctement.
Karpathy a étendu cette approche au recrutement : éviter les questions basées sur des énigmes et confier un projet concret, par exemple la création d’une version sécurisée de Twitter, puis faire en sorte que des agents tentent de la compromettre, tout en observant comment le candidat gère les outils, les spécifications et la supervision. Cela teste la discipline plutôt que la vitesse de frappe.
Trois compétences reviennent constamment dans les discussions avec les dirigeants du domaine de l’ingénierie :
- Fluidezza dans la spécification. Rédiger une spécification suffisamment précise pour que l’agent puisse l’exécuter sans ambiguïté est plus difficile que d’écrire du code. Le code dispose d’un compilateur pour détecter les erreurs, tandis qu’une spécification ne repose que sur l’interprétation de l’agent. Si la spécification est vague, l’agent choisira une interprétation avec assurance, s’y basera pour construire son travail et présentera le résultat comme étant exactement ce qui a été demandé.
- Jugement en matière d’orchestration. Savoir quoi déléguer et quoi garder pour soi, quand des exécutions parallèles sont utiles et quand le couplage est trop étroit, ainsi que déterminer si les résultats nécessitent une revue approfondie plutôt qu’une simple vérification structurelle. Cela se construit au fil de centaines de délégations, chacune permettant de comprendre ce qui fonctionne et ce qui crée des problèmes d’intégration.
Gergely Orosz l’a bien exprimé : il existe quelque chose de bien plus important que la programmation qui rend les ingénieurs exceptionnels, et cela mérite d’être cultivé. Ce qui distinguera les ingénieurs en 2026, ce seront les systèmes qu’ils conçoivent, les spécifications qu’ils rédigent, leur jugement concernant la délégation et les normes de qualité qu’ils refusent d’abaisser. Ces compétences ont aujourd’hui encore plus de valeur précisément parce que l’exécution mécanique a été automatisée.
Un plan de démarrage sur cinq jours
Cinq exercices répartis sur une semaine, chacun s’appuyant sur le précédent :
- Lundi : documenter les connaissances de l’équipe. Rédigez un CLAUDE.md ou des .cursorrules pour le projet en cours. Omettez la liste des technologies et notez les conventions : la manière de gérer les erreurs, la structure des tests, la nomenclature des éléments, ainsi que les règles non écrites que tout nouveau membre doit apprendre dès le premier jour.
- Mardi : spécifier et déléguer. Choisissez une fonctionnalité en attente d’implémentation et rédigez sa spécification à l’aide du modèle : ce qu’elle doit faire, ce qu’elle ne doit pas faire, les critères de succès et les signaux d’échec. Déléguez entièrement sa réalisation à un agent, et prenez en compte le temps nécessaire tant pour la spécification que pour la révision. Ce rapport montre où vont réellement les efforts.
Une semaine ne fera pas de quiconque un ingénieur d’agents. Elle montre cependant à quoi ressemble cette discipline, et détermine si passer de l’écriture de code à l’orchestration d’agents stimule ou épuise. Les deux réponses sont valables, mais il est utile de savoir laquelle est vraie.
Où une vision basée uniquement sur les spécifications manque
Considérer la spécification comme étant la réponse complète, à laquelle il suffit de se fier pour l’écrire, la suivre et la vérifier, est nécessaire mais insuffisant. La spécification constitue une entrée pour un système d’orchestration et non une pratique autonome. Une spécification parfaite transmise à un seul agent permet d’obtenir de bons résultats. La même spécification, distribuée entre cinq agents travaillant en parallèle, chacun soumis à des règles codifiées, examiné dans le cadre d’une supervision structurée et suivi tout au long du processus de développement observable, permet d’obtenir environ dix fois plus de résultats avec la même qualité.
Il est également facile de sous-estimer le niveau 4. La spécification indique l’intention, et c’est l’être humain qui décide si cette intention a été respectée. Une spécification ne s’impose pas d’elle-même, et son étape de vérification exige autant de discipline que sa rédaction. C’est lors de la vérification, plus que avec le modèle, le cadre ou les outils, que la plupart des équipes prennent des raccourcis lorsque les délais se resserrent.
Que vient ensuite ?
Deux orientations sont visibles, l’une quasi certaine et l’autre spéculative.
Celle qui est presque certaine, c’est que l’ingénierie agente deviendra la méthode par défaut pour le développement logiciel professionnel d’ici environ 18 mois, non pas parce que tout le monde en entend parler, mais parce que ses avantages économiques sont irrésistibles. Trois ingénieurs qui l’appliquent, avec des spécifications solides, une orchestration parallèle et un contrôle rigoureux, produisent autant de résultats que douze personnes travaillant selon les méthodes traditionnelles. Lorsque les calculs sont aussi clairs, le débat s’achève.
L’orientation spéculative concerne les essaims agents : des réseaux d’agents qui coordonnent leurs actions entre eux pour gérer des flux de travail ou des fonctions commerciales entières avec un minimum d’intervention humaine. Certaines équipes expérimentent déjà cette approche. Il reste à savoir si elle pourra être maintenue à l’échelle des entreprises avec un niveau de fiabilité équivalent, et il est préférable d’accompagner l’intérêt pour cette technologie d’un esprit sceptique.
Ce qui n’est pas spéculatif, c’est que le rôle de l’ingénieur a déjà changé. La question cruciale est de savoir si les compétences nécessaires pour ce nouveau rôle – spécification, orchestration et vérification – sont en train d’être développées, ou si le travail se poursuit comme s’écrire du code était encore la tâche principale. Autrefois, taper le code constituait la tâche principale. Aujourd’hui, il s’agit de concevoir le système qui génère ce code et de s’assurer que ce qui est produit est correct.