
Développement
Le vibecoding fascine parce qu’il promet quelque chose que tous les DSI et CTO recherchent : produire plus vite. Mais derrière la démonstration impressionnante d’un site ou d’une application générés en quelques minutes se cache une question beaucoup plus importante : qui est responsable des choix techniques, fonctionnels et architecturaux qui ont été faits ?
Car si le code apparaît rapidement à l’écran, la maintenabilité, l’évolutivité et l’intégration au système d’information, elles, se jouent sur plusieurs années.
Depuis l’arrivée des modèles génératifs capables d’écrire du code, une opposition s’est installée dans le monde du développement logiciel. D’un côté, ceux qui considèrent que l’IA va remplacer une partie du travail des développeurs. De l’autre, ceux qui la regardent avec méfiance et préfèrent continuer à travailler comme avant.
Pour nous, cette question est mal posée.
Elle suppose un choix binaire entre deux camps : les agences qui résistent à l’IA ou n’assument pas son utilisation, et celles qui s’y abandonnent corps et âme. La réalité du développement logiciel en 2026 est bien plus intéressante que cela.
Opposer « avec IA » et « sans IA » n’a plus beaucoup de sens. Refuser l’IA aujourd’hui serait une posture idéologique. Les modèles d’intelligence artificielle permettent d’augmenter le développeur. Ne pas s’en servir reviendrait à demander à un menuisier d’oublier l’électricité parce qu’il préfère les outils manuels. Ce choix rendrait, sans aucun doute, son travail non compétitif sur le marché.
Les chiffres vont d’ailleurs dans ce sens. Plusieurs études sectorielles publiées ces dernières années montrent qu’une majorité de développeurs utilisent désormais régulièrement des assistants IA dans leur quotidien, que ce soit pour générer du code, documenter des fonctions ou accélérer certaines tâches répétitives. L’IA est devenue un outil de travail. La question n’est donc plus de savoir s’il faut l’utiliser, mais comment l’utiliser correctement.
Et c’est précisément là que le sujet du vibecoding devient intéressant.
Le vibecoding désigne une pratique qui semble simple. Vous formulez un prompt, et l’IA produit du code.
Vous pouvez par exemple demander :
« Fais-moi un site vitrine pour mon entreprise. »
Quelques minutes plus tard, un site existe devant vos yeux.
Le résultat est souvent bluffant. Le problème est qu’il donne parfois l’illusion que le développement logiciel se résume à produire du code.
Or le code n’est que la conséquence d’une série de décisions.
Quand vous donnez un prompt à une IA, vous lui demandez en réalité d’inventer tout ce que vous n’avez pas précisé.
Autrement dit, un Large Language Model ou LLM, c’est-à-dire un modèle statistique entraîné sur d’immenses volumes de données, va prendre les décisions à votre place en sélectionnant les réponses les plus probables.
Ce qui est inventé, ce sont des moyennes statistiques.
C’est comme cela qu’une IA fonctionne. C’est mathématique.
Finalement, vous obtenez une structure de page moyenne, une logique métier que vous n’avez pas définie et des choix techniques que vous n’avez pas validés.
Oui, le code fonctionne.
Mais il n’est pas forcément aligné sur votre besoin réel, parce qu’aucun besoin n’a été formulé ou challengé précisément.
Pour un projet personnel ou un prototype, cela peut suffire.
Pour une application métier connectée à un ERP, un CRM ou un système de production, les conséquences peuvent être beaucoup plus importantes.
Le véritable sujet n’est pas la génération initiale du code.
Le véritable sujet est ce qui se passe après.
Une application n’est jamais figée. Elle évolue. Les métiers changent. Les processus s’adaptent. Les utilisateurs demandent de nouvelles fonctionnalités. Les réglementations évoluent. Les systèmes existants se transforment.
À ce moment-là, une question devient centrale :
Qui comprend réellement les décisions qui ont été prises lors du développement ?
Dans un projet construit principalement en vibecoding, la réponse est parfois floue.
Les choix ont été réalisés par l’IA.
Les arbitrages n’ont pas toujours été documentés.
Les conventions n’ont pas forcément été définies.
Et lorsque vient le moment de faire évoluer l’application, la dette technique commence à apparaître.
La dette technique représente l’ensemble des compromis ou raccourcis qui rendent un logiciel plus coûteux à maintenir dans le temps. Plusieurs études estiment d’ailleurs que la maintenance corrective et évolutive représente la majorité du coût total d’un logiciel sur son cycle de vie.
Pour un DSI ou un CTO, c’est souvent là que se joue la rentabilité réelle d’un projet.
Le coût de la première livraison est visible.
Le coût des dix évolutions suivantes l’est beaucoup moins.
Or c’est précisément celui qui finit par peser le plus lourd.
Chez Yoozly, lorsque nous avons intégré l’IA dans nos workflows, nous nous sommes posé une question simple :
Comment obtenir d’une IA un projet et un code source qui ressemblent exactement à ceux que nous aurions écrits ?
Non pas un code statistiquement probable, mais un projet qui respecte parfaitement nos conventions, comme s’il avait été conçu par nous.
La réponse tient en deux mots : context engineering.
Le context engineering consiste à fournir à l’IA un cadre extrêmement précis avant même qu’elle ne commence à produire du code.
L’effort et l’expertise se déplacent alors en amont des développements, avant même qu’une seule ligne de code ne soit écrite.
Nous produisons des spécifications denses qui contiennent :
Chez nous, la rédaction de ces spécifications est systématique avant tout développement significatif. C’est un travail parfois invisible pour le client, mais il conditionne directement la qualité du résultat final.
Et le contexte change tout.
Une IA bien contextualisée n’invente plus, car elle s’exécute dans un cadre.
Le LLM génère alors du code que nos développeurs reconnaissent comme le leur, car c’est le leur.
Là où le vibecoding remplit le vide par des moyennes statistiques, le context engineering remplit le vide par notre expertise d’agence digitale au service de nos clients depuis plus de vingt ans.
Le contexte, aussi riche soit-il, ne suffit pas.
Le second pilier de notre approche s’appelle le human in the loop.
Derrière cette expression se cache un principe simple : un humain reste présent à chaque étape critique du processus.
Chaque ligne générée passe entre les mains d’un développeur.
La refactorisation consiste à améliorer la structure interne du code sans modifier son comportement fonctionnel, afin qu’il reste plus lisible, plus robuste et plus facile à maintenir.
Le développeur est l’auteur du projet.
Et il le reste.
Cette boucle humaine garantit que le livrable final correspond exactement à ce que nous voulions produire, et pas à une approximation statistique.
Prenons l’exemple d’une ETI industrielle du bassin lillois souhaitant digitaliser un processus de validation interne impliquant plusieurs services, un ERP et des workflows métier complexes.
Une approche purement orientée vibecoding pourrait générer rapidement une interface fonctionnelle.
Mais qui vérifiera la cohérence des échanges avec l’ERP ? Les règles de gestion spécifiques ? Les droits utilisateurs ? Les mécanismes de traçabilité ? Les performances lorsque plusieurs centaines d’utilisateurs se connectent simultanément ?
C’est précisément là que l’expertise humaine conserve toute sa valeur.
L’IA accélère la production.
Les développeurs garantissent la pertinence des décisions.
L’impact de cette approche se ressent autant à l’intérieur de l’agence que chez nos clients.
Pour nos développeurs, l’IA n’a pas remplacé l’expertise.
Elle l’a déplacée.
Notre équipe consacre davantage de temps à l’architecture, à la qualité logicielle, à la sécurité, à la performance et à la revue de code.
Elle passe moins de temps à écrire des portions répétitives ou standardisées.
Le métier devient plus exigeant, pas moins.
Pour nos clients, le bénéfice se mesure dans la durée.
Un code généré par IA peut parfaitement fonctionner le jour de sa mise en ligne.
Mais il commencera probablement à coûter cher dès la première évolution si personne ne comprend réellement les décisions qui ont conduit à sa construction.
À l’inverse, un projet développé avec une démarche de context engineering et de human in the loop reste maintenable parce que les décisions structurantes ont été pensées, documentées et validées par des humains.
Pour des projets de refonte, de création d’intranet, de digital workplace, d’espace client ou d’application métier, cette différence détermine souvent le coût total de possession du projet sur plusieurs années, et pas seulement le coût de la livraison initiale ou du MVP.
Alors, Yoozly fait-il du vibecoding ?
Non.
Mais oui, Yoozly utilise l’IA dans son processus de développement.
La différence est importante.
Nous ne demandons pas à l’IA de prendre les décisions à notre place. Nous lui demandons d’exécuter plus rapidement des décisions qui ont déjà été prises, documentées et validées.
C’est toute la nuance entre produire du code rapidement et produire un logiciel durable.
Pour un DSI ou un CTO, l’enjeu n’est pas simplement de savoir si un prestataire utilise l’IA. L’enjeu est de comprendre comment il l’encadre, comment il garantit la qualité du code généré et comment il préserve la maintenabilité du projet dans le temps.
C’est précisément la philosophie que nous appliquons dans notre offre Application métier & automatisation : concevoir des outils sur mesure qui s’intègrent à votre système d’information, automatisent les processus utiles et restent évolutifs sur la durée.
Un projet d’application métier ? Parlons-en avec l’équipe Yoozly.

Développement

Développement

Développement