Le principal obstacle au développement logiciel n'est plus l'écriture du code, mais la décision de ce qu'il faut construire, comment l'intégrer et comment le maintenir face aux évolutions. Pendant vingt ans, le problème résidait dans la capacité de production ; aujourd'hui, la production de code est abondante et peu coûteuse, et la pénurie se concentre désormais sur les choix de conception qu'aucun outil de génération de code ne peut prendre à votre place.
Cela a une conséquence concrète pour toute entreprise achetant des services de développement en 2026 : le tarif horaire de programmation diminue, tandis que le coût d’une mauvaise décision architecturale augmente. Acheter comme si nous étions encore en 2019 – en comparant les prestataires uniquement sur le prix et la rapidité – revient à optimiser le mauvais critère.
L'intuition voudrait que si la production de code est plus rapide, les projets se terminent plus vite. Les données racontent une tout autre histoire.
Le rapport DORA 2024, établi par Google Cloud auprès d'environ 39 000 professionnels du secteur, a révélé qu'une augmentation de 251 000 milliards de tonnes de code (TP3T) de l'adoption de l'IA était corrélée à une baisse de 1,51 000 milliards de tonnes (TP3T) du débit de déploiement et de 7,21 000 milliards de tonnes (TP3T) de la stabilité. Ce phénomène n'était pas dû à une mauvaise qualité intrinsèque du code généré, mais à l'augmentation de la taille des lots de modifications : davantage de code était déployé simultanément, les revues étaient moins approfondies et le nombre de dysfonctionnements augmentait. Dans cette même étude, 39,21 000 développeurs ont déclaré avoir peu ou pas confiance dans le code généré par l'IA.
GitClear, analysant 211 millions de lignes de code entre 2020 et 2024, a documenté l'autre face du même phénomène : le code remanié ou « déplacé » est passé d'environ 251 TP3T en 2021 à moins de 101 TP3T en 2024, tandis que le copier-coller est passé de 8,31 TP3T à 12,31 TP3T et les blocs dupliqués ont été multipliés par huit.
Traduction : On écrit plus, on réorganise moins. Cela s'accumule.
L'étude de METR de juillet 2025 a introduit une nuance qu'il convient d'aborder avec franchise. Lors d'un essai contrôlé mené auprès de 16 développeurs open source expérimentés et portant sur 246 tâches concrètes, les participants ont mis 19% de plus à réaliser les tâches avec l'IA, alors même qu'ils s'attendaient à être 24% plus rapides et qu'après le test, ils étaient toujours convaincus d'avoir été 20% plus rapides. METR a lui-même réexaminé ce protocole en février 2026 afin de déceler un éventuel biais de sélection, et une cohorte plus importante a révélé une différence bien moindre. Le résultat exact fait débat. Ce qui est incontestable, en revanche, c'est la conclusion secondaire : la vitesse perçue et la vitesse réelle sont dissociées.
Lorsque la perception de la vitesse se déconnecte de la réalité, la discipline qui corrige le tir n'est pas l'exécution, mais la conception.
Toutes les décisions techniques n'ont pas la même importance. La distinction pratique réside entre ce qui peut être modifié en une semaine et ce qui façonnera les cinq prochaines années.
Type de décision | Exemple | Coût du changement ultérieur |
Outil | Framework frontend, bibliothèque graphique | Faible : semaines |
Fournisseur de modèles | Passer d'un LLM à un autre | En dessous, s'il existe une couche d'abstraction |
Modèle de données | Comment représenter un client ou une commande | Haut : affecte tout ce qui est construit au-dessus. |
Frontières entre les systèmes | Quel module possède quelles informations ? | Très élevé : réécriture partielle |
Modèle de permis | Qui peut voir et faire quoi, et avec quelle traçabilité ? | Très élevé : implique sécurité et conformité |
Les deux premières lignes sont celles qui suscitent le plus de discussions lors des réunions techniques. Les trois dernières déterminent si, dans trois ans, l'entreprise pourra faire évoluer son système ou devra le réécrire entièrement.
Un exemple concret et récurrent dans les secteurs de la logistique, de l'assurance et de la santé est la décision de savoir si un « dossier patient » est une entité autonome avec son propre cycle de vie ou simplement une vue construite à partir d'autres tables. Cette décision est prise dès la deuxième semaine du projet, presque toujours sans discussion, et détermine pendant des années si les modifications peuvent être auditées, si la conservation des données peut être appliquée et si le dossier peut être accessible à un tiers via une API. Aucun générateur de code ne prendra cette décision, car il ne s'agit pas d'une question de programmation : c'est une question métier.
Voici le travail que nous faisons dans Développement de logiciels personnalisés [lien interne] Avant d'écrire la première ligne : définissez ce qui existe, ce qui possède quoi et le contrat que chaque module a avec les autres.
L'architecture d'un système d'entreprise est définie par quatre limites. Lorsque ces quatre limites sont bien définies, le système évolue. Si l'une d'entre elles devient floue, le système se dégrade, même si le code est impeccable.
La frontière des données. Chaque donnée doit avoir un seul propriétaire : un système qui la commande et d’autres qui l’interrogent. L’alternative – trois systèmes écrivant la même information – engendre des contradictions qu’aucun niveau supérieur ne peut résoudre et constitue la cause première de la plupart des projets de veille stratégique qui se soldent par des désaccords sur la validité des données.
La frontière des contrats. Les modules communiquent via des interfaces explicites, versionnées et documentées. Un contrat est une promesse : « voici ce que je fournis, voici ce que je garantis, voici ce que je modifie après préavis ». Sans contrat, chaque intégration implique un nouveau couplage et chaque modification fait l’objet d’une négociation.
La frontière des permis. Les droits d'accès (qui peut voir quoi et qui peut faire quoi) devraient constituer une couche du système, et non une condition répétée à quarante endroits. Cette frontière est devenue cruciale avec l'arrivée des agents d'IA qui exécutent des actions : si le modèle d'autorisations était fragile avec les utilisateurs humains, il s'effondre avec les identités non humaines.
La limite de l'observabilité. Un système où il est impossible de savoir ce qui s'est passé, quand et pourquoi, est impossible à maintenir et à auditer. De plus, depuis l'introduction de composantes probabilistes dans la chaîne, la traçabilité n'est plus une simple bonne pratique opérationnelle, mais une exigence de gouvernance.
Ces quatre limites structurent une architecture composable, une approche que nous développons en détail dans notre analyse sur architecture composable, API et intelligence artificielle
Un audit formel n'est pas nécessaire pour détecter les premiers symptômes. Voici les indicateurs qui apparaissent en premier :
Lorsque trois de ces symptômes ou plus apparaissent, l'augmentation des capacités de développement n'accélère rien. Elle ne fait qu'accroître le nombre de personnes en attente d'une décision de conception.
L'argumentaire en faveur de l'architecture est souvent présenté en termes d'ingénierie, ce qui explique son manque d'adhésion aux comités de direction. En langage commercial, une bonne architecture remplit quatre fonctions mesurables :
Réduisez le coût du changement d'avis. Une entreprise capable de modifier son offre, son processus de facturation ou son modèle de tarification en quelques semaines est concurrentielle différemment d'une entreprise qui a besoin de six mois.
Transformez la technologie en un atout, et non en une dépense récurrente. Un système dont la propriété du code est clairement définie, documentée et assortie de contrats explicites est précieux lors d'une vérification préalable. Un système dépendant d'un fournisseur unique ne l'est pas.
Il permet de remplacer des pièces sans avoir à reconstruire l'ensemble. Cela est particulièrement pertinent pour les modèles d'IA, dont les prix, les capacités et les politiques d'utilisation changent plusieurs fois par an.
Cela permet de contrôler les décisions. Avec un cadre réglementaire européen de plus en plus strict, il est important de pouvoir démontrer ce que le système a fait et quelles données sont passées du statut de données souhaitables à celui de données obligatoires.
Chez The Cloud Group, cette approche est formalisée dans TCG-SAF™, notre cadre d'architecture système : cinq étapes – Vision, Domaines, Modules, Ingénierie, Exécution – et un document d'architecture unique qui encadre l'ensemble du projet. Il ne s'agit pas d'un choix esthétique, mais bien de la raison pour laquelle nous pouvons garantir des délais par écrit : une date ne peut être fixée que lorsque le périmètre du projet est défini avant le démarrage.
Au plus fort de l'engouement, on supposait que si tous avaient accès aux mêmes modèles, les performances s'égaliseraient. Or, c'est l'inverse qui s'est produit. Deux entreprises disposant d'un accès identique aux mêmes outils obtiennent des résultats radicalement différents, et cette différence tient à leurs données propriétaires, à leur expertise métier et à la qualité de l'intégration de leurs systèmes.
Les modèles se banalisent. Les outils de génération de code se banalisent. Ce qui ne se banalise pas, c'est la capacité de transformer des fonctionnalités génériques en un système spécifique, fiable et propriétaire.
Cette capacité porte un nom ancien et plutôt peu glamour : l'ingénierie.
L'architecture logicielle désigne l'ensemble des décisions relatives aux composants existants, aux informations qu'ils contiennent et à leurs interactions. Elle est plus importante que le code lui-même, car ce dernier peut être réécrit en quelques semaines, tandis que la modification du modèle de données ou des limites entre les systèmes peut nécessiter une refonte partielle du produit.
Les symptômes typiques incluent : les petites modifications prennent autant de temps que les grandes, les estimations sont peu fiables, chaque nouvelle intégration coûte autant que la première, certaines zones du système sont évitées par l’équipe et la connaissance du flux d’informations dépend d’une seule personne.
Non : cela l’augmente. Lorsque la génération de code est peu coûteuse, la rareté se déplace vers le choix des éléments à développer et de leur interconnexion. Le rapport DORA 2024 a constaté qu’une adoption accrue de l’IA était corrélée à une moindre stabilité des livraisons, précisément parce que le volume de changements augmente sans que la rigueur de la conception ne suive.
Les trois aspects les plus coûteux à modifier sont le modèle de données (la représentation des entités métier), les limites de propriété entre les systèmes (quel module contrôle quelles informations) et le modèle d'autorisations et de traçabilité. Changer de framework ou de fournisseur de modèles est relativement peu coûteux.
Cela dépend du degré de couplage, mais généralement, le coût augmente de façon non linéaire avec le temps : chaque mois de développement basé sur une limite mal définie ajoute du code qui dépendra de cette décision. C’est pourquoi un audit technique précoce coûte généralement beaucoup moins cher que la réécriture qu’il permet d’éviter.
Oui. L'approche habituelle consiste à isoler le système existant derrière des contrats explicites et à remplacer les domaines un par un, plutôt que de tout réécrire d'un coup. Cela nécessite une évaluation préliminaire qui détermine quel domaine moderniser en premier en fonction des risques et de la valeur ajoutée pour l'entreprise.
Soupçonnez-vous que votre architecture soit l'obstacle ? Notre audit technique logiciel fournit un diagnostic écrit de l'architecture, du code, de la dette technique et de la sécurité sous 10 jours ouvrés à prix fixe. Aucune proposition commerciale n'est incluse : diagnostic d'abord, décision ensuite. Demander l'audit → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
