Agentic Engineering : la nouvelle ère de la modernisation cloud

Une migration applicative se heurte rarement à la difficulté d’écrire du code. Elle se heurte au volume : des centaines de milliers de lignes à cartographier, des dépendances implicites, des règles métier qui n’existent que dans le code, une infrastructure dont personne n’a le schéma à jour. C’est exactement le type de travail où un collectif d’agents apporte autre chose qu’un assistant.

• Analyse de dépôts entiers et cartographie des dépendances réelles, pas déclarées
• Identification des domaines fonctionnels enfouis dans un monolithe
• Proposition d’une architecture cible et de ses frontières de service
• Génération et refactoring de code à l’intérieur d’un cadre défini
• Écriture des tests qui n’ont jamais existé
• Conteneurs, infrastructure as code et chaînes CI/CD
• Documentation d’architecture et d’APIs produite en même temps que le code
• Analyse de sécurité et de dépendances vulnérables

Aucune de ces tâches n’est nouvelle. Ce qui change, c’est qu’elles cessent d’être séquentielles et bornées par la disponibilité des rares personnes capables de les mener de bout en bout.

Une fois l’architecture cible arbitrée et validée, l’exécution peut s’industrialiser : découpage en services, génération et refactoring du code, définition des APIs, conteneurisation, infrastructure as code, tests, scripts de migration, documentation.

La nuance est importante : l’agent n’improvise pas une architecture pendant qu’il code. Il applique celle qui a été décidée. Ce qui suppose qu’elle existe ailleurs que dans la tête de quelqu’un — sous forme de spécification.

Un cycle agentique n’est pas une boîte noire entre une demande et un déploiement. Chaque étape produit un artefact que l’on peut lire, contester et rejouer.

Chaque rôle correspond à un métier déjà existant dans une équipe d’ingénierie. C’est volontaire : un découpage qui ne ressemble à rien de connu est un découpage que personne ne saura superviser.

Un agent sans contexte produit des résultats plausibles et incohérents entre eux. Il ne connaît ni les conventions de l’organisation, ni ses contraintes réglementaires, ni les raisons des choix passés — et il comblera ces vides par des réponses raisonnables dans l’absolu, inadaptées en l’espèce.

Le contexte à fournir ressemble beaucoup à ce qu’on explique à une personne qui rejoint l’équipe :

• L’architecture existante et les décisions qui l’ont façonnée
• Les conventions de code et de nommage réellement appliquées
• Les règles métier, y compris les exceptions
• Les politiques de sécurité et les contraintes de conformité
• Les conventions d’APIs et le design system
• La stratégie de test attendue

En pratique, cela prend la forme de fichiers d’instructions versionnés à côté du code — conventions, règles d’ingénierie, spécifications. Peu importe l’outil qui les lit : ce qui compte est que ces règles soient écrites, révisées et versionnées comme le reste. Un contexte qui vit dans une conversation disparaît avec elle.

Un agent capable de modifier du code et de déclencher des déploiements est, du point de vue de la sécurité, un acteur du système d’information. Il se traite comme tel : avec une identité, des droits limités et des journaux.

• Moindre privilège : chaque agent n’obtient que les droits nécessaires à sa fonction, et rien de plus
• Exécution isolée, sans accès latéral à ce qui ne le concerne pas
• Aucun secret en clair dans un contexte d’agent ; gestion centralisée et rotation
• Revue de code obligatoire sur ce qui est produit, exactement comme pour un humain
• Analyse continue des dépendances introduites
• Journaux d’audit permettant de reconstituer qui a fait quoi, quand et pourquoi
• Approbation humaine explicite pour les opérations irréversibles
• Confidentialité des données : un agent ne devrait jamais voir plus que ce que sa tâche exige

L’erreur à éviter est de donner à un agent un accès large « pour que ça marche », puis de restreindre plus tard. Les permissions provisoires ont une espérance de vie étonnamment longue. Notre approche de ces sujets est détaillée sur la page Sécurité & confiance.

La crainte d’un remplacement se dissipe assez vite en pratique. Ce qui se transforme, c’est la répartition de l’effort : produire des lignes de code occupe moins de temps, et tout ce qui détermine la qualité de ces lignes en occupe davantage.

L’Agentic Engineering ne corrige rien de ce qui relève de la décision humaine. Il n’efface ni une architecture mal pensée, ni des données de mauvaise qualité, ni des règles métier qu’aucun document ne tranche, ni une dette technique accumulée, ni une gouvernance absente.

Il faut même le dire plus franchement : l’automatisation amplifie les décisions, bonnes comme mauvaises. Une convention discutable appliquée à la main sur dix fichiers reste un détail ; la même convention appliquée par des agents sur quatre cents fichiers devient un problème structurel.

D’où quatre conditions qui ne sont pas optionnelles : une gouvernance claire, un contexte explicite, des spécifications écrites et une validation humaine aux points irréversibles.