L'essentiel à retenir selon nos experts
change de nom...
IA & Vibe Coding, pourquoi la complexité remet l'expertise au centre ?
Disclaimer : Cet article est un retour d'expérience de terrain, pas une vérité absolue. On pourrait m'objecter que je n'exploite pas encore ces outils à leur plein potentiel et c'est probablement vrai. Mais qui peut affirmer aujourd'hui que tous les développeurs de demain maîtriseront parfaitement ces nouvelles pratiques ? Nos processus évoluent, notre apprentissage aussi. Ce que je livre ici est une étape de réflexion, ancrée dans mon quotidien de développeur chez Codéin.
Le concept fait grand bruit : le Vibe Coding. L'idée est de ne plus coder "à la main", mais d'insuffler une intention à une IA, Claude, Cursor, GPT-4, qui se charge de générer l'intégralité du code.
Pour un développeur, c'est une libération de la charge mentale liée à la syntaxe. Pour un décideur, c'est la promesse de livrer plus vite, avec moins de ressources. Mais comme nous allons le voir, cette promesse tient sur des projets ciblés et se fissure dès que la complexité monte.
L'IA est un accélérateur indéniable sur plusieurs phases clés. Voici les cas d'usage où le gain est concret avec les nuances qui vont avec.
Exemple : Prototypage rapide pour arbitrage client : Mandatés pour mettre à jour une application VTiger fortement surchargée pour gérer des forecasts de production, nous avons rapidement senti que la vraie question n'était pas "comment migrer" mais "est-ce que ce produit est encore le bon outil". En quelques heures, nous avons généré un prototype d'application sur mesure couvrant le cas d'usage client, ce qui aurait demandé plusieurs jours de maquettage classique. Le client s'est retrouvé avec deux options chiffrées et une projection visuelle concrète de chacune. Il a choisi le développement sur mesure. Ce prototype n'a pas été repris tel quel, mais il a servi de base solide pour la phase de conception graphique et a évité des semaines d'aller-retour sur des spécifications abstraites.
Le gain de productivité n'est pas linéaire. À mesure que le projet grossit, la courbe s'aplatit puis la dette s'accumule.
C'est l'effet le plus contre-intuitif, et le plus sous-estimé. On s'attend à gagner du temps partout. En réalité, on passe moins de temps à écrire, mais beaucoup plus de temps à relire. Et c'est une relecture d'un type particulier : il faut comprendre du code qu'on n'a pas écrit, dans un style qui n'est pas le sien, pour valider qu'il fait bien ce qu'on croit qu'il fait.
La tentation est forte de valider un bloc qui "semble marcher". C'est là que la dette technique s'installe silencieusement, non pas parce que le code est faux, mais parce qu'il n'est pas complètement adapté au contexte du projet.
Exemple : Quand le projet grossit, l'IA perd le fil : Sur un pipeline de données Airflow parti de zéro, le démarrage s'est très bien passé : j'avais une architecture claire en tête, je pilotais l'IA brique par brique, les résultats étaient cohérents. Puis, à mesure que le projet grossissait, les réponses sont devenues moins pertinentes. Du code similaire apparaissait à plusieurs endroits avec de légères variations; des classes avec des signatures légèrement différentes là où une base commune bien conçue aurait suffi. Quand j'ai voulu refactorer avec l'aide de l'IA, je me suis heurté à un autre problème : trop de code à analyser, les limites de contexte atteintes rapidement, des résultats insatisfaisants. J'ai fini par faire le refactoring seul, à la main.
Bilan : une demi-journée perdue à travailler avec l'IA avant de comprendre qu'il fallait travailler sans elle.
Sans encadrement architectural constant, l'IA empile des rustines plutôt que de simplifier l'existant. C'est ce qu'on pourrait appeler le vibe coding spaghetti : un code fonctionnel en apparence, difficile à maintenir en pratique, où les couches s'accumulent sans logique apparente et où remonter la chaîne d'exécution demande beaucoup de temps.
Exemple : La rustine qui cache la fissure : Sur un projet React, une fonctionnalité de filtrage côté client posait problème : les résultats étaient incohérents selon l'ordre des interactions. Plutôt que d'identifier la cause racine ( un état mal initialisé en amont) l'IA a proposé une série de corrections locales : un useEffect supplémentaire ici, une condition de garde là. Ça passait les tests. Deux semaines plus tard, un nouveau développeur intègre le projet et doit faire évoluer ce composant. Il lui faut des heures pour comprendre pourquoi trois mécanismes différents gèrent en réalité le même état, et pourquoi en toucher un casse les deux autres. Ce n'est pas du code faux, c'est du code spaghetti : chaque couche avait une raison d'être à l'instant T, mais l'ensemble est devenu illisible.
Autres symptômes courants :
Ma conviction : l'IA ne remplace pas le développeur, elle transforme son rôle en pilote de haute précision. Et piloter s'apprend.
Découper le problème : Ne pas demander "fais-moi un module de facturation". Guider brique par brique, valider chaque interface avant de passer à l'implémentation.
Imposer les standards dès le départ : Contraindre l'IA à respecter les patterns du projet : injection de dépendances, typage strict, conventions de nommage. Ce travail de cadrage initial conditionne la qualité de tout ce qui suit.
Maîtriser la fenêtre de contexte : Donner à l'IA uniquement les fichiers strictement nécessaires. Une fenêtre surchargée produit du code incohérent avec l'existant. C'est un travail de sélection chirurgicale.
Reprendre la main au bon moment : Savoir identifier quand l'IA tourne en rond ou empile des corrections sur des corrections. Le "prompting circulaire" (corriger les erreurs de l'IA par l'IA) est un signal d'alarme : il faut sortir du contexte et reprendre le contrôle manuellement.
Demander des structures, pas des implémentations : Obtenir d'abord les interfaces, les contrats de données, les schémas puis laisser l'IA implémenter. Ça préserve la cohérence architecturale et économise les quotas.
Exemple Airflow; Définir avant d'implémenter : Sur un pipeline Airflow d'une dizaine de DAGs, j'ai commencé par demander à l'IA de définir les interfaces de chaque opérateur personnalisé, signatures, paramètres attendus, comportement en cas d'erreur, avant toute implémentation. Ce cadrage initial a pris une demi journée. Résultat : les opérateurs générés ensuite s'emboîtaient naturellement, sans duplication. Le refactor de mi-projet s'est limité à quelques fichiers bien structurés.
Même sur un projet entièrement piloté par IA, certaines dimensions restent hors de sa portée. Et ce n'est pas une question de temps ou de version du modèle, c'est structurel.
La relation client et l'arbitrage métier : L'IA peut générer dix options techniques en trente secondes. Elle ne peut pas savoir laquelle est acceptable pour ce client, dans ce contexte budgétaire, avec cette contrainte politique interne que le chef de projet a mentionnée entre deux cafés.
L'arbitrage métier repose sur une connaissance du terrain, des personnes et des enjeux que l'IA n'a pas et qu'aucun prompt ne peut lui transmettre complètement. C'est précisément là que réside la valeur d'un partenaire technique de confiance, par opposition à un simple exécutant.
La gestion de l'imprévu et du risque : Une spécification qui change en cours de sprint, un environnement de production qui se comporte différemment de la recette, l'imprévu est par définition ce qui n'était pas dans le contexte initial. L'IA excelle dans un périmètre stable et bien défini. Dès que les hypothèses de départ bougent, c'est l'expérience humaine qui reprend la main : évaluer l'impact, recalibrer les priorités, rassurer l'équipe et le client.
La transmission et la montée en compétence : C'est la dimension la plus souvent oubliée dans les discours sur l'IA. Un projet ne se termine pas à la livraison. Il y a une équipe qui va maintenir, faire évoluer, comprendre les choix faits. Si le code a été généré sans que personne ne l'ait vraiment pensé, la transmission devient un problème. Former un développeur junior, expliquer pourquoi une architecture a été choisie plutôt qu'une autre, garantir que la connaissance reste dans l'équipe et pas seulement dans un historique de prompts, c'est un travail humain, délibéré, qui ne se délègue pas.
La décision finale et la responsabilité : L'IA peut préparer un arbitrage, résumer des options, rédiger un compte rendu. Mais signer, assumer, répondre d'un choix devant un client ou une direction, ça reste à l'humain. Et c'est heureux : la responsabilité est ce qui donne du sens à l'expertise.
Si nous pilotons bien ces outils, nous gagnons en qualité globale. Des spécifications à jour, une couverture de tests systématique, une documentation vivante, c'est un niveau de rigueur que peu de projets pouvaient s'offrir auparavant. L'IA rend ces bonnes pratiques plus accessibles, moins chronophages à mettre en place, plus faciles à maintenir dans la durée. C'est un levier réel pour des équipes qui manquent de temps, pas une promesse de qualité sans effort.
Mais la promesse "créer une application complète en quelques heures sans connaissances techniques" ne résiste pas à l'épreuve d'un produit industriel, maintenable et évolutif. Ce qu'on gagne au démarrage, on peut le reperdre, avec intérêts, si on laisse la complexité s'installer sans garde-fou. Le vibe coding spaghetti n'est pas une fatalité, c'est le résultat d'un pilotage insuffisant.
La vraie question n'est donc pas "l'IA va-t-elle remplacer les développeurs ?", elle est déjà dépassée. La question qui compte aujourd'hui est : comment intégrer ces outils dans une pratique d'ingénierie rigoureuse, sans sacrifier la cohérence, la maintenabilité et la transmission ? C'est un apprentissage collectif, qui demande du recul, de l'expérimentation, et une honnêteté sur les limites, les siennes comme celles des outils.
Nos métiers changent. Le développeur de demain sera plus architecte que codeur, plus pilote qu'exécutant. Mais il restera celui qui comprend ce qu'il construit, qui en assume la cohérence, et qui peut l'expliquer à un client, un collègue ou un successeur. C'est ça, l'expertise, et c'est précisément ce que l'IA ne génère pas.
On peut "viber" un prototype. On ingénie une solution qui dure.
RAG, MCP, hébergement souverain, sans magie, sans promesses floues.
L'IA métier, c'est notre métier.
Notre approche
L'IA métier, c'est notre métier.
Notre approche
Votre cas d'usage mérite mieux qu'une démo.
Démarrons un POC