La conception logicielle AI-first depuis les premiers principes : guide du praticien

La plupart des équipes ont adopté l’IA sans réviser une seule hypothèse en dessous, ce qui explique pourquoi la production est devenue plus rapide et les systèmes plus mauvais.

Voici la question que la plupart des équipes d’ingénierie n’ont pas encore posée à voix haute : si le modèle peut écrire le code, en quoi sommes-nous censés être bons désormais ?

Les réponses que j’entends sont surtout défensives. L’ingénierie de prompts. La relecture du résultat de l’IA. Savoir vers quel outil se tourner. Toutes de vraies compétences, toutes en aval du basculement réel, et aucune n’explique ce que je vois sans cesse en pratique : des équipes qui ont adopté les mêmes outils, le même trimestre, avec les mêmes modèles, et qui finissent à des endroits complètement différents. Un groupe livre plus vite et le logiciel tient. L’autre livre plus vite et passe le trimestre suivant à découvrir ce qu’il a cassé.

Mêmes outils. Résultats opposés. Cette différence ne vient pas du modèle.

L’amplificateur que personne n’avait prévu

Le rapport 2025 de DORA sur le développement logiciel assisté par IA a chiffré cela. 90 % des professionnels de la technologie utilisent désormais l’IA au travail, et plus de 80 % estiment qu’elle a accru leur productivité. Ces deux constats ne surprennent pas. Celui qui compte est le troisième : une adoption plus forte de l’IA est associée à une hausse du débit de livraison logicielle et à une hausse de l’instabilité de cette livraison, en même temps.

Relisez-le, parce que c’est tout l’argument. L’outil a rendu les équipes plus rapides à livrer et moins bonnes à maintenir les choses en marche. Pas l’un ou l’autre. Les deux.

Le cadrage de DORA est que l’IA est un amplificateur : elle magnifie la pratique sur laquelle elle atterrit. Les systèmes solides deviennent plus solides. Les systèmes faibles deviennent plus rapides à être faibles.

Ce qui signifie que la question intéressante n’a jamais été « comment adopter l’IA ». C’était « qu’est-ce que l’IA amplifie chez nous ». Et y répondre exige de remonter plus loin que n’importe quelle décision d’outil.

Raisonner depuis le problème, pas depuis l’outil

La pensée par premiers principes fait partie de ces expressions répétées jusqu’à perdre leur sens, alors soyons précis sur ce que j’entends par là et sur ce que je n’entends pas.

Raisonner par analogie, c’est à quoi ressemblait la plupart des adoptions de l’IA. Nous avions une méthode de développement. Une nouvelle capacité est arrivée. Nous avons demandé où cette capacité s’insère dans la méthode, nous l’avons ajoutée au point de moindre résistance (généralement la rédaction du code) et nous avons gardé tout le reste identique. Réunions quotidiennes, tickets, sprints, revue : tout préservé. La méthode était traitée comme un donné et l’outil ajusté à elle.

Raisonner par premiers principes pose une question plus dure. Dépouillez le processus jusqu’à ce qui est réellement, physiquement vrai dans la construction d’un logiciel. Puis demandez lesquelles de ces vérités le modèle a changées et lesquelles il n’a pas touchées. Reconstruisez à partir de ce qui survit.

Faites-le honnêtement et vous constaterez que l’IA a changé exactement une chose, et ce n’est pas celle que la catégorie vend.

Le coût de production du code est tombé presque à zéro. Le coût de décider ce que le code doit être n’a pas bougé.

Tout ce qui est utile découle de cette seule asymétrie. Voici les quatre conséquences que je voudrais que tout praticien puisse énoncer de mémoire.

Un : le modèle de données est le produit

L’écran est la partie la plus volatile de toute application et l’endroit le plus tentant pour commencer, parce que c’est la partie qu’on voit. C’est aussi la partie qui devrait être la moins coûteuse à jeter.

Le modèle de données est l’inverse. Il décide ce que vous pouvez demander, ce que vous pouvez indexer, ce que vous pouvez changer plus tard sans une migration qui effraie tout le monde. Chaque capacité en aval est contrainte par des choix faits, ou improvisés, à cette couche.

Quand le code était coûteux, cet ordre s’imposait de lui-même. Personne n’écrivait à la main cent écrans contre un schéma auquel il n’avait pas réfléchi, parce qu’écrire cent écrans à la main prenait un trimestre. La génération a supprimé cette barrière naturelle. Vous pouvez désormais produire une interface entière contre un modèle de données qu’aucun humain n’a jamais relu, et cela aura l’air terminé.

L’ordre doit donc devenir délibéré. Le modèle d’abord, puis le contrat, puis l’interface. Pas parce que c’est traditionnel, mais parce que c’est le seul ordre où les décisions coûteuses sont prises tant qu’elles sont encore bon marché à changer.

Deux : une décision reportée est quand même prise

C’est le point que les praticiens sous-estiment.

Toute décision que vous ne prenez pas explicitement est quand même prise. Elle est prise par le générateur, au moment de la génération, depuis un contexte qui n’inclut ni votre activité, ni votre surface de conformité, ni votre historique de migrations, ni vos plans pour le trimestre prochain. Le modèle ne refuse pas de décider. Il choisit quelque chose de plausible et poursuit.

Que peut encore voir un utilisateur dont l’abonnement est résilié ? Que se passe-t-il quand deux personnes modifient le même enregistrement ? Une adresse e-mail est-elle unique, et unique par rapport à quoi ? Personne n’a posé ces questions, donc personne n’y a répondu, et l’application a désormais une réponse aux trois, choisie par déduction, découvrable seulement en la heurtant en production.

C’est le mécanisme derrière ce que les communautés de constructeurs ont nommé le problème des 70 %. Le progrès s’arrête non pas parce que le travail restant est difficile, mais parce qu’il est bloqué par des décisions prises silencieusement, plusieurs centaines de générations plus tôt, et qui ne peuvent plus être changées sans démonter l’ensemble.

La pratique qui corrige cela a désormais un nom : le développement guidé par la spécification. Écrire d’abord les exigences, les contraintes et les critères de réussite. Traiter ce document comme la source de vérité. Laisser l’agent construire contre lui. GitHub a publié Spec Kit, AWS a publié Kiro, et la convergence n’est pas une coïncidence.

Trois : quand la génération est gratuite, les contraintes doivent être écrites

Pendant des décennies, la justesse était en partie portée par le coût d’écriture du code. Un développeur qui implémentait une règle devait garder cette règle en tête. La connaissance tacite dans une tête humaine était un endroit acceptable pour stocker une contrainte, parce qu’un humain était toujours dans la boucle.

Cet emplacement de stockage ne fonctionne plus. Si une contrainte n’est pas exprimée quelque part de lisible par une machine (une contrainte de schéma, un type, une règle de validation, un test, une ligne explicite dans une spécification) elle n’existe pas du point de vue du générateur. Elle n’existe que dans la mémoire de celui ou celle qui va être surpris.

C’est le cœur pratique de la conception AI-first, et il n’a rien de glamour. Poussez les invariants vers la couche qui peut les faire respecter. Non-null et unique dans la base de données plutôt que dans un gestionnaire de formulaire. Des types aux frontières plutôt que dans un commentaire de code. L’autorisation comme une politique que le système évalue plutôt qu’une condition que quelqu’un a pensé à écrire dans un point d’accès.

Chaque contrainte que vous externalisez est une décision que le modèle ne peut plus rater.

Quatre : vous construisez désormais pour deux consommateurs

Le dernier point est le plus récent, et celui que la plupart des équipes n’ont pas du tout intériorisé.

Votre application a désormais deux types d’utilisateurs. L’un est une personne qui regarde un écran. L’autre est un agent qui appelle une API, qui ne voit jamais votre interface et qu’un bon design ne peut pas persuader. Si une capacité existe dans votre interface mais pas dans votre API, alors du point de vue de l’économie des agents elle n’existe pas.

Cela a une conséquence de conception : la parité n’est pas un agrément. Tout ce qu’un humain peut faire via l’interface devrait être atteignable via une surface définie, documentée et découvrable. C’est aussi pourquoi GraphQL convient mieux que REST à la consommation par des agents : un schéma auto-descriptif est quelque chose qu’une machine peut explorer sans qu’un humain écrive d’abord des notes d’intégration.

Construisez pour l’agent et l’interface humaine se simplifie comme effet secondaire. Construisez uniquement pour l’humain et vous replaquerez une API sous la pression d’un délai, ce qui est le pire moment possible pour en concevoir une.

À quoi ressemble le fait de sauter cette étape, dans les données

GitClear a analysé 623 millions de modifications de code de 2023 à 2026, et le tableau de la maintenabilité est cohérent avec tout ce qui précède.

Par rapport à la référence de 2023, les blocs de code dupliqués sont en hausse de 81 %. Le copier-coller au sein d’un même commit est passé de 9,4 % en 2022 à 15,7 % au premier semestre 2026. Les constructions qui masquent les erreurs sont en hausse de 47 %. Pendant ce temps, les appels de fonctions entre fichiers, le signal le plus clair disponible de réutilisation de code, sont en baisse de 35 %, et l’activité de refactorisation s’est effondrée de 21 % des modifications en 2022 à 3,8 % jusqu’ici en 2026.

Les développeurs sont désormais environ cinq fois plus susceptibles de copier-coller que de refactoriser. En 2022, ce rapport allait dans l’autre sens.

Rien de tout cela n’est un problème de qualité de modèle. La duplication au lieu de la réutilisation, la gestion d’erreurs qui avale au lieu de faire remonter, la refactorisation qui cesse d’avoir lieu : voilà ce qu’on obtient quand la génération est bon marché et que la structure n’est le travail explicite de personne. Le résultat est localement plausible et globalement incohérent, ce qui est précisément le mode de défaillance qu’une méthode partant de l’écran ne peut pas détecter.

Comment travailler ainsi, dès cette semaine

Rien de tout cela n’exige une réorganisation. Cela exige de changer l’ordre de quatre ou cinq habitudes.

1. Écrivez le modèle de données avant le premier écran. Entités, relations, cardinalité, ce qui rend une ligne unique, ce qui cascade à la suppression. Une heure ici est l’heure la plus rentable du projet, et c’est celle que les outils vous invitent activement à sauter.
2. Faites de la spécification l’artefact que vous relisez, pas du diff. Si la spécification est juste et que la génération lui est fidèle, relire des milliers de lignes de code généré est du théâtre. Relisez le document qui les a produites. Débattez de la spécification tant que débattre est encore bon marché.
3. Externalisez toutes les contraintes que vous pouvez nommer. Avant de générer, listez les règles qui ne doivent jamais être violées et placez chacune quelque part où le système les fait respecter. Tout ce qui reste dans la conversation finira par être violé par quelque chose qui n’a jamais rejoint la conversation.
4. Concevez l’API comme la surface du produit. Puis traitez l’interface humaine comme un consommateur parmi d’autres. C’est un choix d’ordonnancement plus que d’ingénierie, et l’ordonner tard est ce qui le rend coûteux.
5. Instrumentez pour l’instabilité, pas seulement pour le débit. Le constat de DORA est que la vitesse et la fragilité ont augmenté ensemble : ne mesurer que la vélocité vous montrera la bonne moitié de votre propre tendance. Le taux d’échec des changements et le temps de rétablissement sont les chiffres qui vous disent si l’amplificateur travaille pour vous.

Ce que cela coûte

Je veux être direct sur le compromis plutôt que de prétendre qu’il n’y en a pas.

Travailler ainsi est plus lent la première semaine d’un projet et nettement plus rapide toutes les semaines suivantes. C’est un coût réel, payé d’avance, exactement au moment où l’élan semble le plus précieux et où un concurrent livre quelque chose de visible. Il y aura des sprints où l’équipe qui a sauté tout cela aura l’air de gagner.

Ce n’est pas gratuit en discipline non plus. Écrire des contraintes est moins plaisant que regarder une interface apparaître. Relire une spécification est moins satisfaisant que relire du code. Ces habitudes se dégradent sous la pression des délais, qui est la même pression qui les rend importantes.

Et une partie ne s’applique véritablement pas. Si vous validez une idée ce week-end et comptez jeter le résultat, jetez-le : rien de ce qui précède ne vaut la peine pour un logiciel qui a deux jours d’espérance de vie. L’argument ici porte sur les applications qui survivent à leur démonstration.

La partie qui n’a jamais été automatisable

Certains rôles bâtis autour de la production de code vont se réduire. Certains vont disparaître. Prétendre le contraire n’aide personne à se préparer, et ceux qui vous disent que tous les postes d’ingénierie sont à l’abri ne vous rendent pas service.

Mais regardez ce que l’asymétrie a réellement fait. Elle a automatisé l’expression des décisions et laissé les décisions elles-mêmes entièrement intactes. Quoi construire. Quoi ne pas construire. Quels invariants tiennent. Ce que le système ne doit jamais faire. Où se situent les frontières et qui est autorisé à les franchir.

Ce travail a toujours été la partie difficile. Il était simplement caché sous le labeur de la frappe, assez coûteuse pour ressembler au métier.

La frappe n’a jamais été le métier.

Lectures liées

La pratique en profondeur : le développement guidé par la spécification. Si vous choisissez un outil : les meilleurs constructeurs d’applications par IA en 2026.

Questions fréquentes

Que signifie « conception logicielle AI-first » ? Concevoir une application en partant de l’hypothèse que la plupart du code sera généré plutôt qu’écrit à la main, et que certains consommateurs seront des agents plutôt que des personnes. En pratique, cela signifie que le modèle de données, les contraintes et le contrat d’API sont définis explicitement en amont, parce que ce sont les décisions que la génération ne peut pas prendre à votre place.

En quoi la conception AI-first diffère-t-elle du simple usage d’outils de code par IA ? Utiliser des outils d’IA ajoute une capacité à une méthode de travail inchangée. La conception AI-first change l’ordre des opérations : modèle et contrat avant l’interface, spécification comme artefact relu, contraintes poussées dans des couches capables de les faire respecter. L’étude 2025 de DORA a trouvé que l’adoption de l’IA augmentait ensemble le débit et l’instabilité, ce qui arrive quand l’outil change mais pas la pratique.

Quels sont les premiers principes de la conception logicielle à l’ère de l’IA ? Quatre tiennent : le modèle de données est le produit et l’écran en est une vue ; toute décision que vous ne prenez pas explicitement est prise implicitement par le générateur ; les contraintes doivent vivre quelque part où une machine peut les faire respecter plutôt que dans la tête de quelqu’un ; et votre application sert désormais à la fois une interface humaine et une API tournée vers les agents, qui ont besoin de parité.

Concevoir ainsi ralentit-il les équipes ? Cela charge le travail en amont plutôt que de l’ajouter. Les décisions capturées dans un modèle de données et une spécification sont des décisions que quelqu’un prend de toute façon : soit délibérément au départ, soit implicitement par un modèle qui devine plus tard. C’est du second chemin que viennent les reprises, et les reprises ne sont pas plus rapides.

Le développement guidé par la spécification est-il la même chose que la conception AI-first ? Le développement guidé par la spécification est la pratique ; la conception AI-first est l’ensemble plus large des conséquences architecturales. Le premier couvre l’écriture de la spécification et la génération contre elle. La conception AI-first couvre aussi l’ordre de la modélisation des données, l’endroit où les contraintes sont appliquées et la conception pour des consommateurs agents en plus des humains.

Quand peut-on sauter tout cela sans problème ? Prototypes, démonstrations, bricolages internes ponctuels et tout ce que vous comptez jeter. Le surcoût ne vaut la peine que pour un logiciel qui doit survivre à de vrais utilisateurs, de vraies données et au changement dans le temps.