Agentic engineering : pourquoi le mid-market DACH reste bloqué à l'étape un

Qu'est-ce que l'agentic engineering, et en quoi est-ce différent du vibe coding?

L'agentic engineering est un cycle de développement logiciel défini, en plusieurs étapes, exécuté par des agents IA sur un produit existant, avec des intégrations, des données réelles, des garde-fous de sécurité et des tests. Le vibe coding, c'est du prototypage rapide pour non-programmeurs sur un terrain vierge. Mêmes modèles sous le capot. Discipline complètement différente.

La confusion entre les deux fait de vrais dégâts. Des équipes essaient le vibe coding sur une codebase vieille de vingt ans, la regardent casser et concluent que l'IA n'est pas prête. L'outil n'a jamais été fait pour ce job.

Un cadre utile : construis ton front-end sur Lovable, connecte-le au coeur de Shopify via l'API. C'est la bonne répartition du travail. Le vibe coding pour la surface, l'agentic engineering pour le système en dessous.

Pourquoi le mid-market DACH est bloqué à l'étape un

Les excuses sont prévisibles. On est spéciaux. Notre codebase est trop complexe. J'ai essayé une fois et ça n'a pas marché.

La version honnête est différente. L'équipe a peur de perdre le contrôle, peur que l'agent fasse mieux qu'elle, peur de devoir apprendre un nouvel outil depuis zéro. Ce ne sont pas des problèmes techniques. Ce sont des problèmes de leadership.

On construit l'étude benchmark AI Monitor 2026 avec l'ETH Zürich et l'Université de Saint-Gall précisément parce que "on fait de l'IA" n'est pas un niveau de maturité. Dans tout le mid-market DACH, le schéma est le même : la maturité IA suit le leadership et la culture, pas la régulation.

Pourquoi le goulot d'étranglement est-il passé de l'ingénierie au leadership?

Pendant deux décennies, l'équipe d'ingénierie était la contrainte de chaque boîte de software. Plus maintenant. Une fois la transformation terminée, ta seule vraie limite, c'est ton budget de tokens. Tant qu'elle n'est pas terminée, la contrainte, c'est le leadership et le product management.

Les développeurs restent prudents face au risque, pour de bonnes raisons. Ça fait des années qu'on leur reproche les retards et la complexité sous-estimée. Demande-leur de construire une feature à l'ancienne et ils savent la chiffrer : un sprint, deux semaines. Demande-leur de la construire avec des agents et ils ne peuvent pas te donner ce chiffre, parce qu'ils ne savent pas encore comment l'agent se comporte. Alors ils retombent sur les outils en qui ils ont confiance.

La seule chose qui casse ce réflexe, c'est un CEO ou un responsable R&D qui dit, explicitement, vous avez le droit d'essayer et le droit d'échouer, tant que vous apprenez quelque chose. Sans cette permission venue d'en haut, rien ne bouge.

Comment mettre l'agentic engineering dans le P&L d'un CFO?

Deux cas, et un CFO reconnaîtra les deux. Le cas coûts : même output avec moins de monde, ou le double d'output avec le même effectif, après une période de transformation. Le cas survie : des boîtes de software cotées, construites sur un seul use case étroit, ont été punies par des baisses de valorisation de l'ordre de 40 à 50 pour cent, parce qu'elles n'ont aucune réponse sur ce que vaut leur produit dans un futur agentique.

Le cas survie est le plus fort. Il fait passer la dépense de "budget innovation" à "rester en activité".

Quand on a fait passer Aioma à 30 personnes en six mois, le calcul était simple : chaque ingénieur supplémentaire était un coût linéaire. Avec une stack agentique, cette droite se plie. C'est la partie qui intéresse vraiment le CFO.

Les trois étapes après le feu vert du leadership

Une fois le leadership engagé, le vrai travail commence. Trois étapes avant de déployer le moindre agent.

Extraire le savoir. Ton produit a grandi pendant des décennies. L'IA sait déjà très bien tout lire : le code, chaque dépendance, la documentation, l'historique Slack, les tickets Jira et support. Une partie du savoir ne vit que dans la tête des développeurs seniors, alors fais-les raconter le système, transcris, et injecte le tout. Le résultat est un hub de contexte structuré, et il doit grandir en continu. Sans ça, l'agent est un junior brillant avec une amnésie chaque matin.

Cartographier le risque de sécurité. Les acteurs malveillants aussi ont l'IA. Les nouveaux modèles deviennent bons pour trouver des vulnérabilités zero-day jamais découvertes avant. Avant de laisser des agents modifier quoi que ce soit, tu veux une vue claire de la sécurité pour savoir quoi corriger en premier.

Construire la suite de tests. Cinquante tests unitaires à cinq pour cent de couverture ne suffiront pas. Il te faut une suite end-to-end complète, idéalement des milliers de scénarios basés sur des données d'usage réelles, éventuellement un jumeau numérique du système. Les agents changent beaucoup de choses, vite. Les tests sont ce qui te dit que ça marche encore.

C'est seulement après ces trois étapes que tu déploies ton premier agent, et tu commences séquentiellement : un module, une API, un front-end. Pas partout à la fois.

C'est l'architecture que Simon Scheurer et moi construisons dans Teklens : un hub de connaissances qui ingère GitHub, Jira, Confluence, Slack, la doc et n'importe quelle API dans un seul graphe interrogeable, avec un runtime d'agents ancré dedans via RAG, et des use cases (assistants de workflow, modernisation SaaS, dossiers de due diligence) construits par-dessus. Le message du schéma : tu ne commences pas par le use case. Tu commences par le hub.

Pourquoi l'agentic engineering est un problème GTM, pas seulement R&D

C'est la partie que la plupart des opérateurs ratent. L'agentic engineering n'est pas qu'une histoire de développement. C'est une histoire de revenu.

Si tu sors une version par an, tu as une tentative par an pour trouver le product-market fit dans la couche agentique de ton produit. Un concurrent qui release chaque mois en a douze. Il va itérer plus vite que toi jusqu'à te rendre hors sujet. Tout l'intérêt de la transformation, c'est de compresser cette boucle pour tester positionnement et valeur assez vite pour que ça compte.

La proposition de valeur elle-même doit changer aussi. Les clients ne veulent plus d'un software où ils saisissent des données et récupèrent un rapport. Ils veulent des résultats et des workflows terminés. C'est un problème de repositionnement, et le repositionnement est un job GTM, pas un job d'ingénierie.

La compression interne compte aussi. Quand le support envoie les escalades directement à un agent, quand le product management priorise 50 sujets au lieu d'en trier 5, tout le moteur de revenu accélère. Des équipes produit agentiques et lean changent tes unit economics, et les unit economics changent ta façon de vendre. Voir Revenue Systems & GTM Engineering pour l'argument complet.

Où est-ce que l'agentic engineering casse?

Trois modes d'échec, par ordre de fréquence.

Le manque de talents. Le skill set est nouveau pour tout le monde, donc il n'y a pas de vivier profond où recruter. Soit tu fais venir quelqu'un avec une vraie expérience, soit tu acceptes une longue courbe d'apprentissage interne. Il n'y a pas de raccourci.

Le fantasme du prompt unique. "Claude code, corrige ça" sur une codebase de vingt millions de lignes va échouer, et l'équipe accusera la technologie au lieu du cadrage. Il faut s'attendre à un processus en plusieurs étapes avec itération, pas à une commande magique.

Le piège du "je peux juste l'acheter". L'échec le plus fréquent que je vois : des boîtes qui veulent acheter l'agentic engineering comme une licence et passer à autre chose. Ça ne marche pas comme ça. Ça s'entraîne, ça ne s'achète pas. Amélioration quotidienne, comme un membre de l'équipe.

Le changement de mentalité, du CEO vers le bas

Arrête de coller l'IA sur ton produit comme une liste de use cases. Construis le système d'exploitation en dessous : contexte, sécurité, tests. Ensuite, lâche les agents.

Le changement va du CEO qui doit apprendre le vibe coding au responsable R&D qui doit être convaincu que ça marche, jusqu'au développeur qui adopte de nouveaux outils et accepte le changement quotidien. Sans ce changement, ça échoue.

Le train est parti. Le bus roule encore.

Tu veux la version hebdo de tout ça? Abonne-toi à la newsletter The Science of GTM pour le décryptage de comment produit, GTM et IA fonctionnent comme un seul système. Ou rejoins la liste d'attente de la cohorte AI GTM Lab si tu veux le playbook en live.

FAQ

Qu'est-ce que l'agentic engineering?

L'agentic engineering est un cycle de développement logiciel défini, en plusieurs étapes, exécuté par des agents IA sur un produit existant, avec des intégrations, des données réelles, des garde-fous de sécurité et des tests. Il se distingue du vibe coding, qui est du prototypage rapide pour non-programmeurs sur un terrain vierge.

Le RGPD est-il le principal blocage à l'adoption de l'IA dans le mid-market DACH?

Non. L'expérience terrain et l'étude benchmark AI Monitor pointent toutes les deux vers le leadership, la communication et la culture comme blocages principaux. La régulation est une contrainte soluble. Le problème le plus dur, c'est d'obtenir l'engagement du leadership et de dépasser l'aversion au risque des développeurs.

Par où commencer l'agentic engineering dans une boîte de software existante?

L'étape un, c'est l'adhésion du leadership, avec un budget pour l'outillage et le coaching et une permission explicite d'échouer. Ensuite, le travail d'ingénierie suit trois étapes : extraire le savoir de la codebase dans un hub de contexte, cartographier le risque de sécurité et construire une suite de tests complète. Ensuite seulement, déployer ton premier agent, un module à la fois.

Pourquoi l'agentic engineering compte pour le go-to-market, pas seulement pour l'ingénierie?

Parce qu'il change la cadence de release, la proposition de valeur et les unit economics. Une itération plus rapide te laisse tester ton positionnement avant tes concurrents. Les attentes des clients passent du software que tu opères aux résultats livrés. Des équipes agentiques plus lean changent ta façon de vendre.

Peut-on acheter une solution d'agentic engineering sur étagère?

Non. L'agentic engineering doit être entraîné et adapté à ton produit, ta codebase et ton process, puis amélioré en continu. Le traiter comme un achat unique est la raison la plus fréquente d'échec des transformations.