L’ingénierie agentique, définition et périmètre

L’ingénierie agentique, par définition, c’est le passage de l’assistance au code à la délégation : au lieu de suggérer la ligne suivante, un agent prend une tâche entière, explore la base de code, écrit, exécute les tests, corrige et ouvre une pull request. Et c’est surtout la discipline d’équipe qui rend cette délégation fiable : l’outillage, les skills partagées, les guardrails en CI, les workflows repensés.

La définition tient donc en deux moitiés, et la seconde est celle qui manque le plus souvent. Une équipe qui délègue sans discipline produit du volume, pas du logiciel. C’est la différence entre une pratique d’ingénierie et du vibe coding à l’échelle d’une entreprise.

La définition : de l’autocomplétion à la délégation

L’autocomplétion accélère la frappe. Le développeur reste l’auteur de chaque ligne, l’outil lui fait gagner des secondes. C’est utile, c’est plafonné, et cela ne demande aucun changement d’organisation.

La délégation change l’unité de travail. On ne confie plus une ligne mais une tâche : reproduire un bug par un test puis le corriger, écrire une migration cadrée, monter une fonctionnalité bien spécifiée de bout en bout. Le développeur passe moins de temps à écrire du code et plus de temps à spécifier, découper et vérifier. Il s’agit de deux organisations du travail, et la seconde ne s’improvise pas.

C’est pour cela qu’acheter des licences ne produit presque rien par lui-même. Les études d’adoption le montrent et notre expérience le confirme : sans méthode, chacun retombe sur l’usage le plus simple, l’autocomplétion, et les métriques de delivery ne bougent pas.

Le périmètre : quatre chantiers, pas un achat

Le premier chantier est l’outillage. Quel agent pour quel usage, avec quels accès, sur quel environnement d’exécution, branché sur quels systèmes internes. Le choix de l’outil compte moins que la façon de l’installer dans le quotidien de l’équipe, et il reste réversible : les outils changent tous les trimestres, la discipline se transporte.

Le deuxième est celui des skills : des instructions réutilisables, versionnées dans vos repos, qu’un agent charge pour une tâche récurrente. C’est le mécanisme qui transforme le workflow d’un développeur en workflow d’équipe, et qui capitalise ce que vos seniors savent faire.

Le troisième, ce sont les guardrails : les exigences de tests, l’analyse statique, les scans de sécurité et les règles de revue appliqués en CI, là où on ne peut pas les contourner. Un agent ne lit pas la charte d’usage. La CI, si. Plus une équipe délègue, plus ce socle porte de poids.

Le quatrième, ce sont les workflows : la taille des pull requests, la place de la revue, le découpage du backlog en tâches déléguables, ce qui reste écrit à la main. La revue de code, en particulier, devient le point de passage critique quand le volume de code produit augmente.

Ce que ça change pour les rôles

Le jugement devient la ressource rare. Savoir spécifier une tâche, reconnaître un mauvais découpage, refuser un diff plausible mais faux : ce sont des compétences de senior, et la délégation les multiplie au lieu de les remplacer. Les seniors sceptiques ont d’ailleurs souvent raison sur les risques, et leurs standards font les meilleurs guardrails.

Pour les juniors, la question est plus ouverte : le code facile, celui sur lequel on apprenait, est celui que les agents écrivent le mieux. Les équipes qui s’en sortent redéfinissent la montée en compétence autour de la lecture critique, du débogage et de la spécification, pas autour du volume de code écrit.

Par où commencer

Pas par un déploiement général. La séquence qui fonctionne commence par un état des lieux (métriques de delivery, état de la CI, maturité de l’équipe), continue par une squad pilote sur du vrai backlog, et ne s’étend qu’une fois le delta mesuré. Nous avons détaillé cette méthode de déploiement et les métriques qui permettent de juger sur pièces.

Le critère de réussite est simple à formuler : du code livré plus vite, sans dégradation du taux de défaut, avec une équipe qui comprend toujours son système. Tant que l’un des trois manque, l’équipe parie.

C’est le travail de notre offre d’ingénierie agentique : installer cette discipline dans votre équipe, sur votre base de code, avec des résultats mesurés contre votre propre baseline.