Un développeur me montre fièrement sa dernière création. En trois semaines, il a construit un agent IA qui fusionne des rapports issus de quatre systèmes internes. La démo fonctionne parfaitement. La direction est impressionnée. Trois mois plus tard, ce même agent est en production et un ticket s'escalade : les chiffres du comité de direction hebdomadaire ne concordent plus. Personne ne peut reproduire d'où l'agent tire ses données. Le développeur explique, honnêtement : « J'ai laissé Copilot générer entièrement cette partie-là. Ça fonctionnait, donc je l'ai laissé tel quel. »

Une histoire comme celle-ci parle rarement d'un mauvais ingénieur. Elle parle d'une industrie qui change à une vitesse folle, et de la façon dont une organisation y répond.

Ceci est le cinquième article de notre série consacrée aux données et à l'IA. Dans les épisodes précédents, nous avons examiné la prolifération incontrôlée de l'IA dans les organisations, le Power Platform comme pont vers une intégration IA maîtrisée, la fondation de données avec Microsoft Fabric et le grounded AI comme approche architecturale. À chaque fois, la technologie était au centre. Cette fois, nous nous penchons sur les personnes qui travaillent avec elle. Car sans le bon état d'esprit, tout investissement technique reste une expérience qui finira par dérailler.

L'agent vibe-codé de notre premier article n'est pas une simple note de bas de page. Il est symptomatique d'un changement fondamental dans la façon dont les logiciels naissent aujourd'hui, et dont ils devront être maintenus demain.

Plus tôt cette année, Andrej Karpathy, ancien responsable de l'IA chez Tesla et l'une des voix les plus influentes du deep learning, a introduit un terme qui a divisé le monde du logiciel en deux camps : le vibe coding.

Sa description était aussi simple que provocante. On s'en remet à l'IA, on décrit ce qu'on veut construire, on accepte ce qu'elle génère sans le comprendre entièrement, et on continue de pousser jusqu'à ce que ça fonctionne. « I'm just vibing », a-t-il écrit. Le code appartient à l'IA. Vous en dirigez l'intention. Les réactions ont été prévisibles : enthousiasme d'un côté, effroi de l'autre. Les deux réactions passent à côté de la vraie question que cette manière de travailler pose à quiconque construit des logiciels, déploie de l'IA ou prend des décisions technologiques pour une organisation.

La bonne question va plus loin que le débat sur le droit d'accepter du code que l'on ne comprend pas entièrement. La bonne question est de savoir ce qui change fondamentalement dans le rôle de l'ingénieur et comment une organisation construit là-dessus. Le vibe coding est là. La question est de savoir comment le gérer.

Le vibe coding est une technique. Le vibe engineering est un état d'esprit. Il fait la différence entre plus de productivité et plus de risque.

Le vibe coding est la pratique par laquelle un développeur utilise des outils IA comme GitHub Copilot, Cursor, Claude ou ChatGPT pour générer du code sur la base d'une intention plutôt que d'une implémentation. Vous décrivez le comportement souhaité en langage naturel. L'IA écrit le code. Vous relisez, testez, ajustez et recommencez.

Dans sa forme la plus radicale, telle que Karpathy l'a décrite, vous acceptez le résultat sans plonger dans la logique sous-jacente. Vous faites confiance au système plutôt qu'à votre propre compréhension de celui-ci. Cela fonctionne étonnamment bien pour des prototypes et pour les situations où la rapidité prime sur la robustesse.

C'est aussi exactement là que la critique se vérifie. Un code que vous ne comprenez pas, vous ne pouvez pas le déboguer. Un code que vous ne comprenez pas, vous ne pouvez pas le sécuriser. Un code que vous ne comprenez pas, vous ne pouvez pas le faire évoluer vers un environnement de production qui sert des milliers d'utilisateurs et qui doit répondre à des exigences de conformité.

Le vibe coding est un outil puissant. Un outil sans savoir-faire est dangereux.

La différence est fondamentale. Le vibe coding est une technique qui permet à des développeurs individuels de produire plus vite. Le vibe engineering est la discipline qui garantit que cette rapidité génère de la valeur plutôt que de la dette technique.

Là où le vibe coding se concentre sur le résultat d'une tâche individuelle, le vibe engineering regarde le système dans son ensemble. Là où le vibe coding accepte qu'un code fonctionne sans être compris, le vibe engineering exige que les décisions architecturales soient étayées. Là où le vibe coding traite l'IA comme une source, le vibe engineering la traite comme une collègue assise à la table, avec ses forces et ses faiblesses.

Le vibe engineering s'appuie sur le vibe coding. C'en est la version mature. Il embrasse les gains de productivité qu'offre le développement assisté par l'IA et les inscrit dans un cadre de savoir-faire, de pensée architecturale et de responsabilité organisationnelle.

Le vibe engineer utilise l'IA comme un chirurgien expérimenté utilise un scalpel : comme un prolongement de son expertise.

Qu'est-ce qui fait qu'on est vibe engineer plutôt que vibe coder ? Cela tient à cinq changements dans la façon de penser, de travailler et de porter la responsabilité.

→ Le résultat : des ingénieurs qui livrent plus vite et écrivent un meilleur code, grâce à une collaboration réfléchie avec l'IA.

Cette histoire ne concerne pas seulement les développeurs. Elle touche tous ceux qui décident aujourd'hui de la façon dont les logiciels sont construits dans leur organisation.

Une organisation qui adopte le vibe coding sans cultiver le vibe engineering voit des gains de productivité impressionnants pendant les trois premiers mois. Puis les problèmes commencent. Du code que personne ne comprend. Des failles de sécurité qu'aucune relecture n'a repérées. Des systèmes impossibles à maintenir. C'est la même prolifération incontrôlée que nous décrivions dans le premier article de cette série, mais un cran plus profond, dans la base de code elle-même.

Le vibe engineering prévient ce scénario. Il rend durables les gains de productivité de l'IA parce que les ingénieurs utilisent l'IA comme un prolongement plutôt que comme un sous-traitant. Un assistant qui code avec eux plutôt qu'à leur place.

Pour les responsables IT : redéfinissez ce que vous attendez des ingénieurs
Le développeur de demain a moins de valeur en tant que « typiste » et davantage en tant que penseur architectural, relecteur critique et collaborateur de l'IA. Adaptez votre recrutement, votre formation et vos critères d'évaluation en conséquence. Dès aujourd'hui.

Pour le C-level : comprenez le paradoxe de la productivité
L'IA augmente la vitesse de production, mais sans vibe engineering, elle augmente aussi vos risques. Les organisations qui investissent maintenant dans les bonnes pratiques autour du développement assisté par l'IA seront les leaders dans deux ans. Celles qui ne le font pas paieront plus tard une lourde facture sous forme de dette technique, d'incidents de sécurité et de retouches.

Pour les développeurs : c'est votre moment
Les ingénieurs qui apprennent aujourd'hui à exploiter au mieux l'IA comme relecteurs, architectes et prompt engineers deviendront les professionnels les plus précieux des dix prochaines années. La barre est plus haute que jamais. Ceux qui progressent avec elle trouveront des opportunités qui n'existaient pas auparavant.

La question n'est plus de savoir si vos ingénieurs vont utiliser l'IA. Cette question a déjà trouvé sa réponse. La vraie question est de savoir comment ils le font : d'une manière qui crée de la valeur, ou qui augmente les risques.

Le vibe engineering est symptomatique d'un changement plus large que l'on observe dans toute l'industrie : le niveau d'abstraction monte. Tout comme on a un jour arrêté d'écrire de l'assembleur pour passer à des langages de programmation de plus haut niveau, on arrête aujourd'hui d'écrire chaque ligne soi-même pour commencer à opérer à un niveau d'abstraction supérieur.

Le savoir-faire ne disparaît pas pour autant. Il évolue. Les meilleurs ingénieurs de la prochaine génération seront jugés sur la qualité des systèmes qu'ils construisent, quels que soient les outils utilisés pour cela. Le nombre de lignes de code qu'ils écrivent personnellement compte de moins en moins.

Ce niveau d'abstraction exige toutefois quelque chose de nouveau : une compréhension plus profonde du pourquoi les systèmes fonctionnent, en plus de savoir comment ils fonctionnent. Lorsque vous déléguez l'implémentation à l'IA, vous ne pouvez faire de bons choix architecturaux que si vous comprenez les principes sous-jacents.

C'est ce que nous entendons chez Xylos par vibe engineering. Pour nous, il s'agit d'une façon de travailler qui exploite pleinement les possibilités de l'IA, avec l'expertise humaine qui reste l'ancrage irremplaçable. Le battage médiatique autour de tout cela est secondaire.

Le passage à la construction assistée par l'IA est plus qu'une question d'outillage. Il touche à la culture et aux compétences. Chez Xylos, nous accompagnons les organisations dans cette transition : nous aidons à choisir les bons outils de développement IA comme GitHub Copilot et Azure AI, à mettre en place des processus de relecture et de gouvernance, et à former les ingénieurs aux nouvelles compétences clés du métier. Vous voulez savoir où en est votre organisation aujourd'hui ? Contactez-nous pour un entretien sans engagement.

Utilisez-vous déjà l'IA dans votre workflow de développement, en tant que vibe coder, vibe engineer, ou quelque part entre les deux ? Je suis curieux de savoir où vous placez la limite.

[Peter Verrykt ](https://be.linkedin.com/in/peter-verrykt)est Business Unit Lead Data & AI chez Xylos et accompagne les organisations dans la transformation des données en valeur business concrète. Il aide les entreprises à regarder au-delà des implémentations techniques et met les données et l'IA au service de meilleures décisions, de plus d'agilité et d'une croissance durable.