Points clés
- Le vibe coding et le développement assisté par IA produisent du code fonctionnel rapidement, et des erreurs architecturales tout aussi rapidement. La vitesse est réelle. La cohérence ne l'est pas.
- Une requête ne contient que ce que son auteur comprend. L'IA amplifie la productivité de celui qui maîtrise le domaine et multiplie les erreurs de celui qui ne le maîtrise pas.
- La majorité de tout logiciel métier est constituée de la plomberie que chaque application nécessite : comptes, rôles, permissions, journal d'audit, validation, import, export, tâches de fond, API. Générer cela à partir de requêtes est là que s'accumule la dette technique.
- Une plateforme applicative métier comme AtroCore livre cette plomberie sous forme de configuration, ce qui laisse au code généré par IA la responsabilité unique de la partie spécifique à votre métier.
- Starbucks remplace les logiciels que ses propres ingénieurs réécrivaient déjà. Ce test s'applique à toute taille d'entreprise. La capacité à construire une fondation à partir de zéro ne s'applique pas.
Les entreprises construisent à nouveau des logiciels métier personnalisés
Pendant des décennies, la question « fabriquer ou acheter » avait une réponse établie. Vous achetiez un logiciel du marché et adaptiez le processus pour le faire fonctionner, car construire soi-même était plus lent et impliquait un coût total de possession que personne ne voulait défendre.
Starbucks est le signe le plus clair que le calcul a changé. L'entreprise dépense environ 400 millions de dollars par an en logiciels, et le responsable technologique Anand Varadarajan a déclaré lors d'un forum interne qu'il existait des opportunités claires de réduire cela, selon les informations sur une présentation interne divulguée. Les ingénieurs utilisent le codage assisté par IA pour construire des remplaçants d'un système de surveillance d'inventaire Microsoft et d'un outil de gestion de maintenance IBM.
Le détail qui mérite d'être copié est le type de logiciels que Starbucks a choisi : les outils que ses ingénieurs modifiaient déjà lourdement. Ce test n'a rien à voir avec la taille de l'entreprise. Un fabricant de matériaux de construction dont la tarification dépend de clauses d'indexation enfouies dans les accords fournisseurs fait face à la même question. Les produits de gestion de contrats gèrent la clause. Relier cela aux usines et groupes de matériaux qui existent déjà dans les données maîtres de ce fabricant est là où les solutions que nous avons évaluées s'arrêtent.
Ce comportement se propage. L'enquête 2026 de Retool auprès de plus de 800 professionnels a révélé que 35 % des entreprises avaient déjà remplacé au moins un outil SaaS par quelque chose construit en interne, et 78 % s'attendaient à en construire davantage.
L'histoire a deux versants. Le logiciel interne déplace le coût des abonnements vers la maintenance et les effectifs plutôt que de le supprimer, et le remplacement du point de vente pour Oracle Simphony est en cours depuis plusieurs années, antérieur aux outils IA. L'IA compresse une partie de ce travail et n'a pas compressé cela. Starbucks absorbe également ce que la plupart des entreprises ne peuvent pas : une organisation d'ingénierie assez grande pour construire une fondation et la maintenir pendant une décennie. Un fabricant de 200 personnes fait face à la même décision sans cette capacité. Pour eux, la vraie question est sur quoi construire, et une plateforme applicative métier qu'ils n'ont pas eu à écrire est la réponse la moins chère disponible. Le vibe coding nomme la fin de cela, où quelqu'un invite une application à exister et expédie ce qui en revient.
Ce qui suit s'applique aussi au cas plus large : les développeurs professionnels utilisant l'assistance IA sur du code qu'ils examinent. Nous construisons des logiciels métier personnalisés avec des fabricants et des distributeurs, donc les arguments proviennent de projets plutôt que d'un tableau blanc.
Ce que l'IA écrit bien et ce qu'elle écrit mal
Veracode a exécuté le même test contre les modèles IA depuis 2023 : 80 tâches de codage, quatre langues, quatre classes de vulnérabilités, aucune instruction de sécurité dans la requête. Dans sa mise à jour du printemps 2026, la correction syntaxique a dépassé 95 % tandis que le taux de réussite en sécurité s'est maintenu près de 55 %. Java a obtenu le pire score à 29 %.
La raison derrière ces chiffres est plus utile que les chiffres eux-mêmes. Les modèles sont forts sur les patterns locaux et faibles pour suivre les données entre fichiers. Le SQL paramétré est un pattern que le modèle a vu flaggé mille fois. Assainir une entrée qui passe par quatre fonctions dans un template est une question de flux de données, et le flux de données nécessite un contexte que le modèle ne possède pas.
Pour une équipe professionnelle, les défaillances intéressantes sont celles qui survivent à l'examen. Un examinateur détecte une vérification nulle manquante ou un nom de variable incorrect. L'examen est beaucoup plus faible sur tout ce qui n'est visible que sur plusieurs fichiers et sur plusieurs semaines, car chaque changement semblait raisonnable seul. La logique non documentée passe aussi, car le code généré qui fonctionne est difficile à contester dans une demande de fusion. Ce qui s'accumule est la dette de compréhension : du code qui s'exécute correctement et que personne dans l'équipe ne peut maintenant expliquer.
La maintenabilité montre la même faiblesse. GitClear a analysé 211 millions de lignes de code modifiées de 2020 à 2024 et, comme rapporté par LeadDev, les blocs dupliqués de cinq lignes ou plus apparaissent huit fois plus souvent en 2024. Les lignes copiées-collées ont surpassé les lignes déplacées pour la première fois dans l'ensemble de données. Les lignes déplacées sont l'empreinte du refactoring, le travail de consolidation de quelque chose en un seul endroit réutilisable.
Dans l'enquête Stack Overflow 2025, la principale frustration, nommée par 66 % des répondants, est que la sortie IA soit proche de correcte sans être correcte. La même enquête quantifie les pratiques : 84 % utilisent ou envisagent d'utiliser des outils IA et 51 % des développeurs professionnels les utilisent quotidiennement, tandis que seuls environ 15 % considèrent le vibe coding comme faisant partie de leur travail professionnel. Le codage assisté par IA est le cas par défaut. Expédier du code non lu reste rare.
Une requête ne contient que ce que son auteur sait
L'IA répond à la requête qui lui a été donnée, donc le plafond du code généré est la compréhension du domaine de celui qui a écrit la requête. Sur les problèmes de données B2B, cette compréhension réside rarement avec le développeur. Un responsable des achats qui a négocié des accords fournisseurs pendant quinze ans sait ce qu'une clause de prix indexée doit supporter. Un développeur qui lance une requête sans cette connaissance obtient du code qui satisfait l'exemple et rien de plus, et l'écart reste invisible jusqu'à ce qu'un vrai contrat arrive.
Pour les équipes professionnelles, cela déplace le goulot d'étranglement. La vitesse de frappe a cessé d'être une contrainte il y a longtemps, et la syntaxe l'a suivie. Ce qui limite la production maintenant est la qualité de l'extraction des connaissances du domaine.
Une hypothèse connexe mérite d'être nommée. Les sociétés de logiciels qui ont passé dix ans sur le même produit n'ont rarement gaspillé ces années. Ce temps contient les cas limites que personne n'avait anticipés, le modèle de permissions qui a survécu à un audit, l'import qui gère la feuille de calcul qu'un fournisseur envoie réellement plutôt que celle décrite par la spécification. Rien de cela n'atteint une requête, car personne ne l'écrit jusqu'à ce qu'il casse une fois en production.
Un développeur expérimenté avec de bons outils IA peut reproduire la forme d'un produit mature en semaines. Reproduire ce qu'il a appris prend à peu près aussi longtemps que la première fois. Nous vendons des logiciels, donc pesez cela en conséquence, puis testez-le : prenez un produit que vous connaissez bien et comptez combien de ses comportements vous auriez pu spécifier à l'avance.
La dette technique se trouve dans la plomberie
Imaginez une application de gestion des fournisseurs. Avant qu'elle ne gère un seul fournisseur, elle a besoin d'une longue liste de choses qui n'ont rien à voir avec les fournisseurs.
Comptes, groupes et rôles, plus des permissions au niveau des champs pour que les achats voient les conditions commerciales et que le responsable usine ne les voit pas. Un journal d'audit enregistrant qui a modifié quel champ et quand. Validation sur chaque champ. Recherche, filtres sauvegardés et modification en masse. Import depuis la feuille de calcul qu'un fournisseur a envoyée, export vers l'ERP. Tâches de fond qui survivent à une mise à jour de 40 000 lignes. Une API REST pour la vue mobile que quelqu'un demandera plus tard.
Rien de cela ne concerne votre problème métier. Tout cela doit fonctionner.
Lancez un agent pour cela, et vous obtenez le contrôle des rôles implémenté d'une manière dans le module fournisseur et d'une autre manière dans le module contrats trois semaines plus tard. Deux mécanismes de permissions qui désaccordent sur les cas limites. Composants suraccouplés, car le modèle a optimisé chaque requête localement et n'a jamais vu l'ensemble. Historique des modifications sur quatre entités et pas sur la cinquième. Chaque pièce fonctionne lors de la démonstration. Ensemble elles constituent la facture de maintenance, et elle arrive que quelqu'un appelle le processus vibe coding ou non.
Parmi les implémentations que nous avons exécutées, la répartition entre plomberie et logique métier spécifique est déséquilibrée de manière cohérente.
La partie spécifique au métier d'un client représente rarement plus d'un dixième de ce qui est construit. Le reste est identique dans chaque application métier jamais écrite, et c'est exactement la partie que l'IA écrit de manière incohérente.
Ce ratio décide l'économie. Le vibe coding est peu coûteux là où le travail est petit et coûteux là où le travail se répète.
Ce qu'une plateforme de données vous remet avant la première requête
La plateforme AtroCore est un logiciel open source sous GPLv3, en développement actif depuis 2018, construite pour la gestion des données maîtres et l'intégration de systèmes. Ses cas d'usage documentés incluent servir de plateforme low-code open source pour les logiciels métier personnalisés.
Disponible par configuration, avant que quiconque n'écrive une ligne de code :
- Modèle de données.
Entités et relations configurables, plus de 20 types de champs avec validation automatique, mises en page configurables, hiérarchies multi-niveaux avec héritage, classification et taxonomies. - Accès et historique.
Utilisateurs et groupes illimités, gestion des rôles, contrôle d'accès au niveau des champs, requêtes d'accès configurables, journaux d'actions, historique des modifications, commentaires, propriété des enregistrements, tableaux de bord, filtres mémorisables. - Mouvement des données.
Flux d'import et d'export, requêtes API et requêtes de bases de données configurables, transformations appliquées avant l'import ou l'export, XLSX, CSV, JSON et XML, connexions via REST, GraphQL, SOAP et OData. - Traitement.
Un gestionnaire de tâches où vous définissez le nombre de workers par rapport à la capacité serveur, tâches programmées, actions basées sur les événements, workflows configurables et contrôles de qualité des données. Boutons d'action personnalisés placés dans l'interface par configuration, chacun s'exécutant sur un seul enregistrement ou une sélection complète. - Résultat.
Modèles PDF, documents Office et email, plus une API REST couvrant tout, y compris votre propre configuration.
Ce qui reste pour le vibe coding est la partie qui est vraiment la vôtre. La formule d'ajustement des prix indexés. La logique de comparaison des appels d'offres. Le connecteur vers ce module ERP que personne n'a intégré avant.
Ce code a des endroits définis où vivre. AtroCore s'étend par des modules que vous écrivez vous-même, et la logique plus légère s'adapte à des actions, scripts et conditions configurables attachés aux entités existantes. Le déclencheur est généralement un bouton configuré, ce qui signifie qu'une opération en masse sur 300 enregistrements sélectionnés n'a besoin d'aucun écran, d'aucune route et d'aucune logique de permissions propre.
Les résultats de Veracode s'appliquent toujours au code que le modèle écrit là. Ce qui change est le rayon d'action. Une formule de tarification dans un système qui gère déjà l'authentification, les permissions au niveau des champs et la validation des entrées a moins de façons de vous faire du mal qu'une dans un point de terminaison fait à la main qui a aussi inventé sa propre gestion de session.
Le contrat API fait le travail de garde-fou
Un détail dans l'architecture d'AtroCore compte davantage pour le travail assisté par IA qu'il n'y paraît. La couche HTTP respecte strictement PSR-7 et PSR-15. Les handlers s'enregistrent par des attributs PHP et sont documentés automatiquement sous OpenAPI 3.0. Selon la documentation du projet, une route qui n'est pas entièrement documentée n'est pas enregistrée, et chaque requête et réponse est validée contre le schéma au moment de l'exécution.
Considérez ce que cela fait à un agent de codage. Il écrit un client, invente un nom de champ plausible, et la requête échoue immédiatement avec une erreur de schéma. Même session, contexte toujours ouvert, la correction coûte trente secondes. Les erreurs détectées dans la session ne deviennent jamais de la dette technique. Sans un contrat à la limite, ce champ inventé n'écrit nulle part silencieusement et ressurgit quatre mois plus tard comme une investigation de qualité des données. Un retour rapide et implacable est ce qui rend le code généré par IA bon marché à corriger, et la plateforme le fournit sans que quiconque le construise.
Ce schéma est aussi ce que vous remettez à l'agent. Parce que la documentation est générée à partir des handlers plutôt que maintenue à côté d'eux, la description OpenAPI de vos propres entités configurées est actuelle par construction, ce qui est rarement vrai d'une spécification maintenue à la main. Donnez à un modèle ce schéma plus vos conventions de nommage et d'accès, et il écrit contre le vrai contrat. Étendez le modèle de données par configuration plus tard, et le schéma se déplace avec lui, donc le contexte de l'agent reste précis sans que quiconque mette à jour un document.
La recherche pointe vers la fondation, pas l'outil
Le rapport DORA 2025 de Google a découvert que l'IA agit comme un amplificateur, amplifiant les forces existantes et les dysfonctionnements existants, avec les plus grands retours provenant du système sous-jacent plutôt que des outils. Le modèle de capacités IA compagnon de Google Cloud est plus spécifique : l'influence positive de l'IA sur la performance organisationnelle est amplifiée là où existent des plateformes internes de qualité. Une deuxième capacité couvre les écosystèmes de données sains : des données internes de haute qualité, accessibles et unifiées. Une plateforme configurable sous votre logiciel métier personnalisé répond aux deux.
Les affirmations de vitesse continuent de se déplacer. L'essai début 2025 de METR a découvert que les développeurs expérimentés mettaient 19 % plus longtemps dans les dépôts matures quand les outils IA étaient autorisés, tandis que sa mise à jour de février 2026 pointe vers une accélération et signale des effets de sélection assez forts pour justifier une refonte. Traitez les chiffres de productivité comme non résolus. Les résultats de maintenabilité n'ont pas changé depuis 2023.
Un exemple de contrat fournisseur de nos projets
Nos clients se tournent vers nous avec une version reconnaissable du même problème. Un fabricant garde les accords fournisseurs sous forme de fichiers PDF sur un lecteur partagé, les conditions clés dans une feuille de calcul, les dates de renouvellement dans le calendrier d'un acheteur. Personne ne peut dire quels accords contiennent une clause d'ajustement des prix liée à un index de matières premières, car cette clause est une phrase dans un document.
Des outils de gestion de contrats standard existent, et ils supposent un workflow de département juridique se terminant à la signature. Cette entreprise avait besoin de contrats reliés à des groupes de matériaux, des usines et des enregistrements de fournisseurs qui existaient déjà dans leurs données maîtres, avec des obligations qui continuent à produire du travail pendant des années après la signature.
Sur la plateforme applicative métier, contrat, clause, renouvellement et obligation sont devenus des entités configurées liées aux enregistrements de fournisseur et de matériau qui existaient déjà. Le contrôle d'accès au niveau des champs a séparé les conditions commerciales des obligations de livraison. L'historique des modifications est venu avec la plateforme, ce qui a importé la première fois que deux personnes n'étaient pas d'accord sur une remise. Un travail programmé a signalé les fenêtres de renouvellement.
Le code personnalisé a couvert deux choses : le calcul d'ajustement des prix basé sur les index et un connecteur alimentant la vérification des factures dans leur ERP. Les deux étaient assez étroits pour être spécifiés précisément et testés correctement. La plateforme limite ce que le code généré peut toucher, et le vibe coding couvre ce qu'il n'était jamais censé savoir sur une entreprise spécifique.
Où tracer la limite entre configuration et vibe coding
La plupart des meilleures pratiques de vibe coding se réduisent à deux questions. Qu'est-ce qui se configure et qu'est-ce qui est généré. L'IA a un rôle à jouer des deux côtés de cette ligne, et les deux parties ne sont pas le même travail.
Configurez tout ce qui est un enregistrement avec des champs, des relations, des permissions et un cycle de vie. Cela couvre plus que la plupart des équipes ne s'y attendent, y compris les workflows d'approbation, les escalades et les vérifications programmées. Les équipes nouvelles dans ce domaine configurent systématiquement trop peu, puis écrivent du code pour faire ce qu'une action configurée ferait déjà.
L'IA aide ici de manière qui est souvent négligée. Demandez-lui comment modéliser un renouvellement de contrat avec héritage, ou quel type de champ convient à une plage de tolérance, et un modèle capable vous guide à travers la configuration. Pointez-la sur l'API REST, et elle peut appliquer cette configuration elle-même. Suggérer et appliquer la configuration est un travail différent de la construction du système, et cela porte un meilleur retour, car une configuration incorrecte se montre dans l'interface en quelques minutes tandis qu'une mauvaise architecture se montre au mois six.
Générez les transformations et les calculs. Une formule, un mapping, un parser, une requête de rapport. Petite surface, résultat attendu clair, facile à tester.
La vérification a une forme concrète ici. Configurez les règles de validation et les contrôles de qualité des données avant de générer quoi que ce soit, puis exécutez la logique générée contre les enregistrements dont vous connaissez déjà les réponses, y compris les cas délicats comme le contrat sans date de fin. La plateforme rejette ce qui casse ses propres règles, donc le calcul échoue bruyamment sur l'enregistrement qui aurait autrement échoué silencieusement en production. Conservez cet ensemble d'enregistrements comme le test de régression pour le prochain modèle que vous essayez.
Une catégorie n'appartient à aucune. Là où une réponse incorrecte est coûteuse et silencieuse, écrivez-la vous-même. Argent, taxes, documentation de sécurité, tout ce qu'un régulateur lit. L'IA peut produire ce code parfaitement bien. La raison d'écrire à la main est que vous avez besoin de l'avoir compris d'abord.
Si vous pouvez le décrire comme des données plus un changement d'état, configurez-le. Si se tromper coûte plus que d'écrire lentement, écrivez lentement.
Ce que cette approche vous coûte
Vous adoptez les conventions de quelqu'un d'autre pour le fonctionnement des enregistrements, des relations, des permissions et des processus. Là où votre modèle mental diffère, du temps va dans la lutte contre la plateforme au lieu de l'utiliser. Lisez la documentation du développeur avant de vous engager.
AtroCore s'exécute sur PHP et nécessite un serveur Linux avec accès root plus PostgreSQL ou MySQL. L'hébergement partagé ordinaire ne l'exécutera pas. Dans nos projets, une fois que quelqu'un connaît le système, un premier modèle de données fonctionnel de quatre ou cinq entités avec relations, mises en page, rôles et historique prend quelques jours. Atteindre cette familiarité prend plus longtemps, c'est pourquoi le retour sur investissement arrive au mois trois.
L'adéquation a des limites. Une plateforme organisée autour des enregistrements, des relations et des processus métier constitue une mauvaise base pour le contrôle en temps réel ou le traitement des signaux. Commencez par un framework pour ceux-ci. La sur-configuration est sa propre dette technique : vingt entités où cinq suffiraient est de la dette technique aussi, plus silencieuse que le code dupliqué et plus difficile à démêler une fois que des données réelles y vivent.
Comment juger une fondation avant de commencer à faire des requêtes
Il y a deux alternatives, et chacune échoue un test différent. Un framework nu vous laisse propriétaire de chaque pièce de la plomberie. Un constructeur low-code résout cela et facture dans une devise différente : le fournisseur possède votre modèle de données, l'hébergement et l'exécution, et la tarification suit le nombre d'utilisateurs. Cet échange fonctionne pour un tableau de bord interne, mal pour un logiciel contenant les contrats fournisseurs pour la prochaine décennie.
Tenez n'importe quel candidat contre cette liste, y compris les deux alternatives ci-dessus.
- Une entité, un champ et une relation, ajoutés sans déploiement.
- Un seul mécanisme de permissions couvrant tout le système, plutôt que plusieurs qui dérivent.
- Une API générée à partir du code et validée au moment de l'exécution, plutôt que documentée à la main et incorrecte en un mois.
- Un historique des modifications que personne de votre équipe n'a eu à construire.
- Du travail de fond qui s'exécute sans une nouvelle entrée cron par travail.
- Une sortie claire : vos données, votre base de données et votre droit de continuer à exécuter le système si le fournisseur disparaît.
La plupart des fondations échouent plusieurs de ces critères. Savoir lesquels, avant la première requête, est la différence entre la dette technique que vous avez choisie et la dette technique que vous avez héritée.