Points clés à retenir
- Le développement Vibe et l'assistance IA produisent du code fonctionnel rapidement, tout comme les erreurs architecturales. La vitesse est réelle. La cohérence ne l'est pas.
- Un prompt contient uniquement ce que comprend son auteur. L'IA amplifie les erreurs de celui qui ne maîtrise pas le domaine.
- La plupart des logiciels métier contiennent de la plomberie que toute application exige : comptes, rôles, autorisations, piste d'audit, validation, import, export, tâches de fond, API. Générer cela à partir de prompts accumule la dette technique.
- Une plateforme données comme AtroCore livre cette plomberie en configuration, laissant au code généré par IA la responsabilité du seul code spécifique à votre métier.
- Starbucks remplace un logiciel que ses propres ingénieurs réécrivaient déjà. Ce test s'applique à toute taille. La capacité à construire une fondation de zéro ne l'est pas.
Les entreprises reconstruisent des logiciels métier sur mesure
Pendant des décennies, la question construire ou acheter avait une réponse établie. Vous achetiez un logiciel prêt à l'emploi et adaptiez le processus, car construire était plus lent et coûtait trop cher.
Starbucks est le signal le plus clair que le calcul a changé. L'entreprise dépense environ 400 millions de dollars par an en logiciels, et son directeur des technologies Anand Varadarajan a déclaré à un forum interne qu'il existait des opportunités claires de réduire ces dépenses, selon un article sur une présentation interne divulguée. Les ingénieurs utilisent le codage assisté par IA pour construire des remplaçants à un système de surveillance des stocks Microsoft et un outil de gestion de maintenance IBM.
Le détail à copier est le logiciel que Starbucks a choisi : les outils que ses ingénieurs modifiaient déjà massivement. 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 se pose la même question. Les produits de gestion des contrats gèrent la clause. L'intégrer aux usines et groupes de matériaux déjà dans les données maître est où ceux qu'on a évalués s'arrêtent.
Le comportement se propage. Une enquête 2026 de Retool auprès de plus de 800 professionnels a trouvé 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 faces. Un logiciel interne déplace le coût des abonnements vers la maintenance et les effectifs plutôt que de l'éliminer, et le remplacement de point de vente pour Oracle Simphony est en cours depuis plusieurs années, antérieurement aux outils IA. L'IA compresse une partie de ce travail sans avoir compressé celle-là. Starbucks absorbe aussi ce que la plupart des entreprises ne peuvent pas : une organisation d'ingénierie assez grande pour construire une fondation et la maintenir une décennie. Un fabricant de 200 personnes se pose la même question sans cette capacité. Pour eux, la question utile est sur quoi construire, et une plateforme données qu'ils ne devaient pas écrire eux-mêmes est la réponse la moins chère. Le développement Vibe nomme la fin de cela, où quelqu'un invite une application en existence et déploie ce qui revient.
Ce qui suit s'applique au cas plus large aussi : des développeurs professionnels utilisant l'assistance IA sur du code qu'ils examinent. Nous construisons des logiciels métier sur mesure avec des fabricants et distributeurs, donc les arguments viennent de projets plutôt que d'un tableau blanc.
Ce que l'IA écrit bien et ce qu'elle écrit mal
Veracode exécute le même test contre les modèles IA depuis 2023 : 80 tâches de codage, quatre langages, quatre classes de vulnérabilités, aucune instruction de sécurité dans le prompt. Dans sa mise à jour printemps 2026, la correction syntaxique a réussi 95 % tandis que le taux de réussite en sécurité s'est maintenu près de 55 %. Java a obtenu le pire résultat à 29 %.
La raison derrière ces chiffres est plus utile que les chiffres eux-mêmes. Les modèles sont forts sur les motifs locaux et faibles pour tracker les données entre fichiers. Le SQL paramétrisé est un motif que le modèle a vu signalé mille fois. Assainir une entrée qui passe par quatre fonctions dans un modèle est une question de flux de données, et cela 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 relecteur attrape une vérification nulle manquante ou un nom de variable incorrect. L'examen est bien plus faible sur tout ce qui n'est visible que entre fichiers et sur des 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, a trouvé des blocs dupliqués de cinq lignes ou plus apparaissant huit fois plus souvent en 2024. Les lignes copiées-collées ont surpassé les lignes déplacées pour la première fois. Les lignes déplacées sont l'empreinte du refactoring, le travail de consolider 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, était la sortie IA presque correcte sans être correcte. La même enquête taille 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 développement Vibe comme faisant partie de leur travail professionnel. Le codage assisté par IA est le cas par défaut. Déployer une sortie non lue reste rare.
Un prompt contient seulement ce que connaît son auteur
L'IA répond au prompt qui lui a été donné, donc le plafond du code généré est la compréhension du domaine de celui qui a écrit le prompt. Sur les problèmes de données B2B, cette compréhension réside rarement chez le développeur. Un responsable des achats qui a négocié des accords fournisseurs pendant quinze ans sait ce qu'une clause tarifaire indexée doit survivre. Un développeur invitant sans cette connaissance obtient du code qui satisfait l'exemple et rien au-delà, et l'écart reste invisible jusqu'à l'arrivée d'un vrai contrat.
Pour les équipes professionnelles, cela déplace le goulot d'étranglement. La vitesse de frappe a cessé d'être la contrainte il y a longtemps, et la syntaxe l'a suivie. Ce qui limite la sortie 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 ont rarement gaspillé ces années. Ce temps contient les cas limites que personne n'avait prévus, le modèle de permission 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. Rien ne parvient à un prompt, car personne ne l'écrit jusqu'à ce que cela casse une fois en production.
Un développeur expérimenté avec un bon outillage IA peut reproduire la forme d'un produit mature en semaines. Reproduire ce qu'il a appris prend à peu près autant de temps que la première fois. Nous vendons un logiciel, alors 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 dès le départ.
La dette technique se trouve dans la plomberie
Imaginez une application de gestion des fournisseurs. Avant de gérer un seul fournisseur, elle a besoin d'une longue liste de choses qui n'ont rien à voir avec les fournisseurs.
Des comptes, des groupes et des rôles, plus des autorisations au niveau du champ pour que les achats voient les conditions commerciales et que le directeur d'usine ne les voie pas. Une piste d'audit enregistrant qui a changé quel champ et quand. Validation sur chaque champ. Recherche, filtres sauvegardés et édition en masse. Import depuis la feuille de calcul qu'un fournisseur a envoyée par email, export vers l'ERP. Des 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.
Aucun de cela n'est votre problème métier. Tout cela doit fonctionner.
Invitez un agent à le faire, et vous obtenez la vérification des rôles implémentée 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 permission qui ne sont pas d'accord sur les cas limites. Des composants suraccouplés, car le modèle a optimisé chaque prompt localement et n'a jamais vu le tout. Historique des modifications sur quatre entités et pas la cinquième. Chaque pièce fonctionne quand on la démontre. Ensemble, c'est la facture de maintenance, et elle arrive que quelqu'un ait appelé ou non le processus développement Vibe.
Sur l'ensemble des implémentations que nous avons menées, la séparation entre plomberie et logique métier est déséquilibrée de manière cohérente.
La partie spécifique au métier d'un client ne dépasse rarement pas un dixième de ce qui est construit. Le reste est le même dans toute application métier jamais écrite, et c'est exactement la partie que l'IA écrit de manière incohérente.
Ce rapport décide l'économie. Le développement Vibe est bon marché où le travail est petit et cher où le travail se répète.
Ce qu'une plateforme données vous donne avant le premier prompt
La plateforme données AtroCore est un logiciel open source sous GPLv3, en développement actif depuis 2018, construite pour la gestion des données maître et l'intégration de systèmes. Ses cas d'usage documentés incluent servir de plateforme low-code open source pour des logiciels métier sur mesure.
Disponible par configuration, avant que quiconque é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 du champ, requêtes d'accès configurables, journaux d'action, historique des modifications, commentaires, propriété des enregistrements, tableaux de bord, filtres stockables. - Mouvement des données.
Flux d'import et export, requêtes API configurables et requêtes de base de données, transformations appliquées avant import ou export, XLSX, CSV, JSON et XML, connexions sur REST, GraphQL, SOAP et OData. - Traitement.
Un gestionnaire de tâches où vous définissez le nombre de workers par rapport à la capacité du serveur, des tâches planifiées, des actions basées sur des événements, des flux de travail configurables, et des vérifications de qualité des données. Des boutons d'action personnalisés placés dans l'interface par configuration, chacun exécutant un seul enregistrement ou une sélection entière. - 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 développement Vibe est la partie qui est vraiment vôtre. La formule d'ajustement tarifaire indexée. 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 emplacements définis. AtroCore est étendu par des modules que vous écrivez vous-même, et la logique plus légère rentre dans 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 ne nécessite aucun écran, aucune route, et aucune logique de permission propre.
Les constatations de Veracode s'appliquent toujours à ce que le modèle écrit là. Ce qui change, c'est le rayon d'explosion. Une formule de tarification à l'intérieur d'un système qui gère déjà l'authentification, les autorisations au niveau du champ et la validation des entrées a moins de façons de vous nuire qu'une dans un point de terminaison bricolé 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 importe plus pour le travail assisté par IA qu'il n'y paraît. La couche HTTP suit strictement PSR-7 et PSR-15. Les gestionnaires s'enregistrent par attributs PHP et sont documentés automatiquement comme 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 lors 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, le contexte est toujours ouvert, la correction coûte trente secondes. Les erreurs attrapé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 refait surface quatre mois plus tard comme une enquête sur la qualité des données. Des retours rapides et impitoyables sont ce qui rend le code généré par IA bon marché à corriger, et la plateforme le fournit sans que quelqu'un ne le construise.
Ce schéma est aussi ce que vous donnez à l'agent. Parce que la documentation est générée à partir des gestionnaires plutôt que maintenue à côté d'eux, la description OpenAPI de vos propres entités configurées est à jour par construction, ce qui est rarement vrai d'une spécification gardée à la main. Donnez à un modèle ce schéma plus vos conventions de nommage et d'accès, et il écrit contre le contrat réel. Étendez le modèle de données par configuration plus tard, et le schéma le suit, donc le contexte de l'agent reste précis sans que quelqu'un mette à jour un document.
La recherche pointe vers la fondation, pas l'outil
Le rapport DORA 2025 de Google a trouvé que l'IA agit comme un amplificateur, amplifiant les forces existantes et le dysfonctionnement existant, avec les plus grands retours provenant du système sous-jacent plutôt que des outils. Le modèle de capacités d'IA complémentaire de Google Cloud est plus spécifique : l'influence positive de l'IA sur la performance organisationnelle est amplifiée là où existent des plates-formes internes de qualité. Une deuxième capacité couvre des écosystèmes de données sains : des données internes de haute qualité, accessibles et unifiées. Une plateforme données configurable sous votre logiciel métier sur mesure répond aux deux.
Les réclamations de vitesse ne cessent de se déplacer. L'essai début 2025 de METR a trouvé que les développeurs expérimentés ont pris 19 % plus longtemps dans les référentiels matures quand autorisés à utiliser les outils IA, tandis que sa mise à jour 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églés. Les constatations en matière de maintenabilité n'ont pas changé depuis 2023.
Un exemple de contrat fournisseur issu de nos projets
Nos clients se tournent vers nous avec une version reconnaissable du même problème. Un fabricant garde les accords fournisseurs comme des PDF sur un disque partagé, les termes 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 tarifaire liée à un indice de matières premières, car cette clause est une phrase à l'intérieur d'un document.
Des outils standard de gestion des contrats existent, et ils supposent un flux de département juridique se terminant à la signature. Cette entreprise avait besoin de contrats joints aux groupes de matériaux, aux usines, et aux enregistrements de fournisseurs déjà dans leurs données maître, avec des obligations produisant du travail pendant des années après la signature.
Sur la plateforme données, le contrat, la clause, le renouvellement, et l'obligation sont devenus des entités configurées liées aux enregistrements de fournisseur et matériau qui existaient déjà. L'accès au niveau du champ a séparé les conditions commerciales des obligations de livraison. L'historique des modifications est venu avec la plateforme, ce qui importait la première fois que deux personnes étaient en désaccord sur une remise. Une tâche planifiée signalait les fenêtres de renouvellement.
Le code personnalisé a couvert deux choses : le calcul d'ajustement tarifaire basé sur l'indice, et un connecteur alimentant la vérification de facture dans leur ERP. Les deux étaient assez limités pour être spécifiés précisément et testés correctement. La plateforme contraint ce que le code généré peut toucher, et le développement Vibe couvre ce qu'il ne saura jamais sur un métier spécifique.
Où tracer la ligne entre configuration et développement Vibe
La plupart des meilleures pratiques de développement Vibe se réduisent à deux questions. Qu'est-ce qui est configuré, 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 autorisations, et un cycle de vie. Cela couvre plus que la plupart des équipes s'y attendent, y compris les flux d'approbation, les remontées, et les vérifications planifiées. Les équipes nouvelles à cela sous-configurent systématiquement, puis écrivent du code pour faire ce qu'une action configurée fait déjà.
L'IA aide ici d'une manière qui est oublié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-le vers l'API REST, et il peut appliquer cette configuration lui-même. Suggérer et appliquer la configuration est un travail différent de la construction du système, et cela porte le meilleur retour, car une mauvaise configuration se manifeste dans l'interface en quelques minutes tandis qu'une mauvaise architecture se manifeste au mois six.
Générez les transformations et les calculs. Une formule, un mapping, un parseur, une requête de rapport. Une petite surface, une sortie attendue claire, facile à tester.
La vérification a une forme concrète ici. Configurez les règles de validation et les vérifications 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 bizarres 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 é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 des deux. Où une mauvaise réponse est chère et silencieuse, écrivez-la vous-même. L'argent, la fiscalité, la documentation de sécurité, tout ce qu'un régulateur lit. L'IA peut produire ce code parfaitement. La raison d'écrire à la main est que vous devez d'abord l'avoir compris.
Si vous pouvez le décrire comme données plus un changement d'état, configurez-le. Si se tromper coûte plus cher 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 autorisations, et des processus. Où votre modèle mental diffère, le temps va à combattre la plateforme au lieu de l'utiliser. Lisez la documentation du développeur avant de vous engager.
AtroCore fonctionne sur PHP et a besoin d'un serveur Linux avec accès root plus PostgreSQL ou MySQL. L'hébergement partagé ordinaire ne le fera pas fonctionner. 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, ce pourquoi le retour sur investissement arrive au mois trois.
La compatibilité est limitée. Une plateforme organisée autour d'enregistrements, de relations et de processus métier est une mauvaise fondation pour le contrôle en temps réel ou le traitement de signaux. Commencez par un framework pour cela. La sur-configuration est sa propre trappe : vingt entités où cinq suffiraient est aussi de la dette technique, plus silencieuse que le code dupliqué et plus difficile à démêler une fois que les vraies données y vivent.
Comment évaluer une fondation avant de commencer à inviter
Deux alternatives concurrencent une plateforme données, et chacune échoue un test différent. Un framework nu vous laisse posséder chaque pièce de la plomberie. Un constructeur low-code résout cela et facture dans une devise différente : le vendeur possède votre modèle de données, l'hébergement et l'exécution, et la tarification suit le nombre d'utilisateurs. Ce compromis fonctionne pour un tableau de bord interne, mal pour un logiciel contenant des contrats fournisseurs la décennie suivante.
Tenez tout 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 permission couvrant le système entier, plutôt que plusieurs qui dérivent à part.
- Une API générée à partir du code et validée lors de l'exécution, plutôt que documentée à la main et fausse au mois suivant.
- Un historique des modifications que personne dans votre équipe n'a dû construire.
- Du travail de fond qui fonctionne 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 vendeur disparaît.
La plupart des fondations échouent plusieurs de ces critères. Savoir lesquels, avant le premier prompt, c'est la différence entre la dette technique que vous avez choisie et celle que vous avez héritée.