« L’IA l’a construit en dix minutes. Mais plus personne n’ose y toucher. »
Nous entendons des variantes de cette phrase de plus en plus souvent. Les outils d’IA écrivent aujourd’hui du code à un rythme impensable il y a quelques années. Un prototype en un après-midi, une nouvelle fonctionnalité entre deux cafés. C’est formidable. Et c’est précisément là que ça se gâte.
Le problème : un logiciel qui grandit plus vite que votre compréhension
Un logiciel sur mesure n’a jamais été aussi facile à générer, ni aussi difficile à croire sur parole. Le code généré par l’IA a en effet une particularité : chaque modification, prise isolément, semble raisonnable, mais l’ensemble devient peu à peu incohérent. L’IA d’aujourd’hui ne sait pas ce que l’IA de la semaine dernière a décidé. Elle résout donc le même problème une nouvelle fois, juste un peu autrement. Trois versions d’« un client » apparaissent dans votre système. La logique est dupliquée. Les patterns s’emmêlent.
Le problème de fond : l’intention derrière le code n’est écrite nulle part. Avec le sur mesure classique, ce savoir se trouvait au moins dans la tête d’un développeur. Avec le « vibe coding » (enchaîner les prompts, accepter le résultat, passer au suivant), le code est la seule chose qui reste. Six mois plus tard, personne, ni humain ni IA, ne peut encore dire quels choix étaient délibérés et lesquels relevaient du hasard.
Le résultat : vous avez payé pour un actif de l’entreprise et reçu une boîte noire avec une date de péremption. Un logiciel qui a commencé comme un gain rapide et qui finit comme une chose à laquelle plus personne n’ose toucher. Gonflé, fragile, impossible à maintenir. Pas parce que l’IA écrit du mauvais code, mais parce que plus personne n’a de vue d’ensemble.
Une vieille idée, de nouveau d’actualité
Le model-driven development (MDD) n’est pas un concept nouveau. L’idée : vous décrivez d’abord ce qu’est votre système (quelles données existent, par quelles étapes passe un dossier, quelles règles s’appliquent) dans un modèle. Le code en découle.
Dans les années 2000, cette idée a largement échoué. Les modèles ne pouvaient jamais saisir cent pour cent de la réalité. Pour les derniers vingt pour cent, les exceptions et le « oui, mais chez ce client-là ça se passe autrement », il fallait quand même plonger à la main dans le code généré. Et à partir de ce moment-là, le modèle mentait.
En 2026, c’est différent, et pour une raison surprenante : l’IA. La même technologie qui rend le vibe coding possible résout aussi la faiblesse du MDD classique. Autrefois, tenir un modèle à jour et en déduire chaque fois une nouvelle application était tout simplement trop lent et trop cher ; aujourd’hui, cela prend une fraction du temps. Et le modèle lui-même n’a plus besoin d’être un schéma rigide : à côté de la structure formelle, il y a de la place pour les exceptions en langue courante, comme « chaque facture passe par ces cinq statuts, sauf pour les clients exonérés ». Le trou qui a eu raison du MDD à l’époque peut aujourd’hui tout simplement entrer dans le modèle.
Le modèle comme garde-fou pour l’IA
Pourquoi cela fonctionne-t-il si bien ? Pour deux raisons.
Un : le modèle limite ce que l’IA peut construire. Si chaque nouvelle fonctionnalité doit s’inscrire dans les briques, les processus et les règles du modèle, l’IA ne peut pas inventer une quatrième variante d’« un client ». Tout ce qui sort du modèle est visiblement un écart. Pas de prolifération silencieuse.
Deux : le modèle rend les modifications lisibles. Relire deux mille lignes de code généré, personne ne le fait sérieusement. Mais une modification du modèle, si : « cette adaptation ajoute un statut au flux des factures et un champ à la fiche client. » Si une petite demande produit soudain une grosse modification du modèle, vous savez que l’IA vous a mal compris, avant même qu’une seule ligne de code existe.
Et comme l’application est générée à partir du modèle au lieu d’être complétée prompt après prompt, couche après couche, elle ne peut pas pourrir comme le fait du code généré : à chaque modification, elle est proprement déduite à nouveau. Le modèle est la source de vérité. L’intention est le build.
Notre approche
Chez Tandem Studio, nous appelons notre approche le model-driven AI development. Nous ne commençons pas par le code, mais par votre activité. Lors d’un atelier, nous consignons ensemble comment vos processus fonctionnent réellement : notre expertise en UX et en processus garantit que chaque flux et chaque cas limite est mis sur la table, y compris ceux auxquels vous ne pensez même plus. Cela devient un seul modèle lisible, et nous en générons une application qui fonctionne. Quelque chose change dans votre activité ? Nous adaptons le modèle et régénérons. D’abord le modèle, ensuite le code. Jamais l’inverse.
Sous le capot, ce modèle est event-sourced : le système ne retient pas seulement l’état actuel, mais chaque événement qui y a mené. Chaque devis envoyé, chaque validation, chaque modification. Le modèle n’est donc pas seulement un plan, mais aussi un relevé des faits de votre entreprise, et il s’accorde parfaitement avec la façon dont nous construisons nos logiciels. Pourquoi nous faisons ce choix, nous l’expliquons dans L’event sourcing pour les logiciels de PME et dans notre article sur l’event sourcing avec DCB.
Le résultat : un logiciel que vous pouvez lire au lieu d’une boîte noire, qui évolue au rythme de votre entreprise, et qui ne s’encrasse pas d’IA superflue sous le capot. Ou, pour le résumer à notre façon : il grandit, sans les douleurs de croissance.
L’IA rend la construction de logiciels plus rapide que jamais. Mais la vitesse sans structure, c’est simplement aller plus vite vers le chaos. La structure, c’est notre métier.
Vous avez un logiciel qui a grandi plus vite que votre maîtrise ? Ou vous voulez construire avec l’IA sans tomber dans ce piège ? Parlez-nous-en, nous regarderons volontiers ensemble où vous en êtes.
