Récemment, j'ai vu souvent apparaître l'expression « Le développement sous contrat est mort » dans mon fil d'actualité. On en parle généralement dans le contexte où l'IA rend la création de logiciels plus rapide et moins coûteuse, ce qui fait que le modèle traditionnel de « construire et livrer exactement ce que le client demande » perd rapidement de sa valeur.
Au début, honnêtement, je me suis dit : « N'est-ce pas juste un autre cycle de hype du style 'X est mort' ? »
Après tout, les gens disent « Le développement sous contrat est mort » depuis des décennies, bien avant l'IA. Le développement en interne, le cloud, la sous-traitance à plusieurs niveaux, la délocalisation – à chaque fois, on a dit « cette fois-ci, ça va vraiment mourir », et pourtant le développement sous contrat survit comme un zombie.
En réalité, j'ai longtemps travaillé pour des entreprises de produits, donc j'observais ces sujets de loin. Je me souviens avoir pensé que le développement sous contrat avait l'air difficile et que je ne voulais pas m'en approcher.
Puis, il y a trois ans, j'ai rejoint Hololab Inc., et je suis maintenant en plein cœur du travail client, y compris le développement sous contrat. Pour être honnête, quand j'ai rejoint l'entreprise, le terme « développement sous contrat » m'a donné quelques réticences. Malgré tout, le défi de la transformation apportée par les nouvelles technologies et l'attrait de l'entreprise elle-même ont prévalu. Je me suis dit qu'il serait peu cool de me plaindre du « développement sous contrat » sans l'avoir réellement expérimenté.
Trois ans ont passé depuis. J'ai rejoint l'équipe de direction et j'ai fait face au développement sous contrat de front. C'est pourquoi, cette fois-ci, je veux affronter l'expression « Le développement sous contrat est mort » sans fuir.
« Le développement sous contrat est mort » est-ce vrai ?
C'est vrai.
Même avant l'IA, il y avait des mouvements vers le no-code dans le contexte de la DX (Transformation Digitale) et une tendance au développement en interne. Puis la vague de l'IA (en particulier les agents IA) est arrivée, et cette tendance s'est intensifiée instantanément. Même les non-ingénieurs peuvent désormais créer des logiciels.
Quand ce sujet est abordé, les ingénieurs qui en vivent ont tendance à faire tout un plat de la « qualité » ou de la « sécurité », arguant que « le développement logiciel n'est pas si facile ».
Cependant, la qualité requise pour un logiciel varie en fonction de son objectif et de son cas d'utilisation. Les logiciels destinés aux clients ou aux environnements de production exigent un certain niveau de service. En revanche, le niveau requis pour les outils internes ou les POC (Proof of Concept) est souvent relativement bas. Et c'est précisément dans ce domaine que le remplacement par les agents IA est facile, ou plutôt, a déjà commencé.
En ce qui concerne la sécurité et la qualité, j'ai l'impression que l'écart se réduit chaque année à mesure que les modèles évoluent et que les connaissances humaines sur l'utilisation de l'IA s'accumulent. Il y a seulement deux ou trois ans, l'avis dominant était que « l'IA peut aider, mais il est trop tôt pour la laisser écrire du code », alors qu'aujourd'hui, l'IA écrit le code plus souvent qu'autrement. En voyant cette vitesse de changement, même dans les domaines où il est actuellement difficile de déléguer complètement, une situation où « l'IA est plus fiable que les humains » pourrait facilement survenir dans un avenir proche.
Pour être honnête, en tant qu'ingénieur moi-même, une partie de moi ne veut pas croire que le travail que j'ai accompli puisse être si facilement remplacé. Mais je vois clairement ce qui est en train de mourir sous mes yeux. Ce n'est pas du battage médiatique ou une question de position ; c'est un changement qui se produit réellement.
Cependant, cela ne signifie pas que « l'ensemble du développement sous contrat est en train de mourir ». Ce qui meurt, ce n'est pas le développement sous contrat, mais le développement logiciel qui se contente de « construire ». Je vais expliquer pourquoi je pense cela.
1. On ne peut pas mettre tous les « développements sous contrat » dans le même panier
Même si l'on dit « développement sous contrat » d'un seul souffle, le contenu varie : des entreprises qui vendent simplement des mois-hommes aux SSII, consultants, partenaires produit, PMO et support DX. La question à se poser n'est donc pas « Le développement sous contrat est-il mort ? » mais « Qu'est-ce qui est exactement mort ? »
En décomposant les choses, la baisse de valeur due à l'IA ne se produit pas d'un coup ; elle progresse par étapes. La première vague frappe la valeur de l'acte d'« écrire du code ». En effet, la productivité du développement augmente et la structure des bénéfices des projets commence à changer.
Et cette vague ne s'arrêtera pas à l'écriture de code. Elle s'étendra progressivement à la conception, à la définition des besoins et à la phase de conceptualisation qui les précède. C'est pourquoi je veux distinguer les valeurs qui chuteront en premier de celles qui resteront.
Donc, ce qui est en train de mourir, c'est le travail consistant à « simplement écrire du code comme on le dit ». Que ce soit du développement sous contrat ou non, cela n'a pas d'importance. Et ce domaine est déjà en train de rétrécir.
Cependant, le rétrécissement n'est pas uniforme. Les petits et moyens développeurs sous contrat et les petits développements en interne ressentent de plein fouet les vagues de l'interne et de l'IA générative, et les projets commencent à disparaître. D'un autre côté, j'entends souvent dire que les systèmes complexes pour les grandes entreprises ne sont pas encore en grande difficulté car ils ne peuvent pas être gérés uniquement par les équipes internes. L'impact varie considérablement en fonction de l'échelle et de la clientèle, donc les mélanger embrouille la conversation.
2. Les clients n'achètent pas du « code » en premier lieu
Quand on réfléchit à savoir si les clients passent contrat parce qu'ils veulent que du code soit écrit, la réponse est non.
Ce que les clients attendent, c'est une résolution de problèmes : ils veulent organiser des stratégies d'entreprise, réfléchir ensemble aux besoins, obtenir de l'aide pour la prise de décision, être assistés dans la coordination interne et réduire les risques. Le code n'est qu'un moyen parmi d'autres pour y parvenir.
En pensant ainsi, la logique selon laquelle « le code est devenu bon marché = le développement sous contrat est mort » est assez myope. Le moyen est devenu moins cher, mais la substance attendue n'a pas du tout disparu.
Cela correspond à ma propre expérience de travail à la fois dans des entreprises de produits et dans le développement sous contrat. Il existe des sites de développement sous contrat qui plongent profondément dans le métier, et des équipes de développement internes qui agissent comme des sous-traitants internes, construisant simplement ce que le département métier leur dit. Tracer une ligne entre « entreprise de produits vs. développement sous contrat » ne rend plus compte de la réalité.
De plus, cela ne concerne pas seulement le développement sous contrat. La frontière entre le développement et le conseil est également en train de fondre. Les cabinets de conseil se dotent de plus en plus d'équipes de développement, et les SSII commencent à soutenir les activités métier. « Le SaaS est mort » suit la même structure : les entreprises qui se contentent de vendre des logiciels sont finies, tandis que celles qui plongent dans le BPO, les opérations, le partenariat et les garanties de performance croissent. Le conseil, les SSII, le SaaS et les entreprises de produits se chevauchent de plus en plus. La destination est la « valeur » pour le client.
3. « Penser » et « Construire » se rapprochent
Pendant longtemps, le coût de construction d'un logiciel était bien trop élevé. Par conséquent, « penser » et « construire » étaient inévitablement séparés. Les rôles étaient divisés, les titres de poste étaient divisés, les organisations étaient divisées, et même les entreprises avaient tendance à être divisées.
L'IA a abaissé le coût de la « construction ». En conséquence, « penser » et « construire » commencent naturellement à converger. Les rôles, les titres de poste, les organisations et les entreprises se rapprochent tous. C'est le changement qui se produit actuellement.
Et ce que le développement Agile voulait atteindre était exactement cela : rapprocher « penser » et « construire ». Nous nous approchons enfin de l'idéal qui n'a pas pu être pleinement réalisé à l'époque parce que le coût de la construction était trop élevé.
En fait, dans notre propre travail client, les cas qui ne se terminent pas par un simple développement augmentent. Ce qui commence comme un développement normal se transforme souvent en « nous voulons des conseils sur la manière de mener l'activité », s'étendant au PMO, à la conception du modèle d'entreprise, à la promotion de projet et au soutien à la prise de décision. De nos jours, il y a des sites où nous passons plus de temps à « construire l'activité » qu'à « construire le système ». Je me suis d'abord demandé si c'était encore du développement sous contrat, mais j'ai cessé de me soucier des frontières.
J'entends beaucoup parler du terme FDE (Forward Deployment Engineer) ces derniers temps, et c'est probablement une partie de la même tendance. Entrer sur le site du client, réfléchir ensemble aux problèmes et écrire du code si nécessaire. Pas un « penseur » et un « constructeur », mais une « personne qui construit en pensant ». Une idée fausse courante ici est que l'essence est d'être sur site ou physiquement proche du client. Ce n'est pas le cas. Il s'agit d'être proche de la résolution de problèmes.
Cependant, ce changement est une arme à double tranchant. J'ai récemment entendu cette histoire dans une grande entreprise : cela a commencé par une stratégie d'entreprise. Le développement du système a commencé. À mi-chemin, la construction est devenue le seul objectif. La stratégie a disparu. Et une énorme quantité de systèmes inutilisés est restée. Cette réalité existait bien avant l'IA. Mais alors que l'IA réduit le coût de la construction, cette tragédie se produira plus facilement et en plus grande volume. Plus il devient facile de construire, plus le poids de « quoi construire » devient lourd.
Par conséquent, pour le développement sous contrat qui plonge dans la résolution de problèmes, l'IA est un vent arrière, pas un vent contraire. C'est loin d'être « mort ». Cependant, au moment où vous vous éloignez de la résolution de problèmes, ce vent arrière se transforme en une « machine de production de masse de choses inutiles ».
4. En fin de compte, la source de valeur, ce sont les « personnes »
Quand on arrive à ce point, il semble que la source de valeur du développement sous contrat, du conseil et du SaaS soit la même. Ce n'est pas le logiciel lui-même. Ce sont les personnes.
Le travail que n'importe quelle entreprise peut résoudre sera remplacé. Le travail que l'IA peut résoudre sera également remplacé. Mais « il faut que ce soient ces personnes qui le résolvent » demeure. « Je veux travailler avec ces personnes » demeure également.
L'objectif n'est donc pas de livrer un produit, mais d'être un partenaire pour le client afin d'atteindre la valeur. Faites-leur ressentir la valeur dans les personnes, pas dans l'objet.
L'exemple parfait est la prise de décision. L'IA peut générer un nombre quelconque de candidats. Mais celui qui décide est un humain. Et on ne s'améliore dans la prise de décision qu'en prenant des décisions.
La façon dont nous formons les personnes change également. Dans mon département, nous évoluons vers « penser + construire », et bien sûr, il y a des difficultés. Mais cela ne s'apprend pas en formation. Cela ne se développe que dans le travail.
Je vais mentionner brièvement le recrutement. Récemment, de plus en plus d'entreprises réduisent le recrutement de juniors à cause de l'IA. La logique est : « Si l'IA écrit du code, nous n'avons pas besoin de juniors. » Mais je crois le contraire. Les juniors natifs de l'IA, parce qu'ils manquent d'idées préconçues, ont le potentiel d'imaginer des façons de l'utiliser qui ne nous viendraient jamais à l'esprit. Même si l'embauche est freinée à court terme, si vous ne pouvez pas créer un environnement où les personnes grandissent, cette industrie ne fera que décliner. Ce n'est pas la faute de l'IA ; c'est juste un échec à s'adapter aux changements que l'IA a apportés.
Le métier d'ingénieur ne disparaît pas. Le travail de l'ingénieur qui « construit simplement » disparaît.
Tout développement logiciel se rapproche de la « valeur »
« Le développement sous contrat est mort » est vrai. Cependant, ce n'est pas le développement sous contrat qui est en train de mourir, mais le développement logiciel qui se contente de « construire ». Ce n'est pas le métier d'ingénieur qui disparaît, mais le travail de l'ingénieur qui « construit simplement ». Et cela a déjà commencé. Le développement sous contrat se trouve simplement en première ligne.
Si vous prenez du recul et regardez ces changements, une image plus grande émerge. Le développement sous contrat qui plonge dans le métier. Les cabinets de conseil avec des équipes de développement. Le SaaS qui s'engage sur des garanties de performance. Les FDE qui entrent sur les sites clients. Les positions et les formats sont tous différents, mais la direction est la même. Tout développement logiciel se rapproche de la « valeur » à sa manière.
De plus, ce n'est pas une nouvelle tendance. Les ingénieurs savent depuis longtemps que « construire ne suffit pas », et ont essayé de se rapprocher des clients, des utilisateurs et de la valeur. L'exemple représentatif est le développement Agile. Cela fait 25 ans qu'Agile est né. Cet idéal de rapprocher « penser » et « construire » est accéléré d'un seul coup par l'IA en ces quelques années. C'est ainsi que je vois les choses.
Donc, nous ne devrions plus être obsédés par la « forme » du développement logiciel. Développement sous contrat ou entreprise de produits ? SSII ou consultant ? Au lieu de gaspiller de l'énergie là-dessus, la question à se poser est : « Jusqu'où pouvez-vous plonger dans la valeur ? »
Le 7/24, j'aurai une discussion en direct sur le thème « Le développement sous contrat est mort » jusqu'au matin
Le 7/24, je parlerai lors d'un événement organisé par Creationline intitulé « L'avenir du développement sous contrat à l'ère de l'IA — Au-delà de 'Le développement sous contrat est mort' ».
https://creationline.connpass.com/event/398146/
Vendredi 24 juillet 2026, de 19h00 à 20h30, organisé via Zoom, participation gratuite.
J'aurai une discussion approfondie et honnête avec @samuraiRed et @sasakendayo sur le thème « Le développement sous contrat est mort ».
Comme nous sommes trois personnes susceptibles de dire des choses que nous ne devrions pas, j'ai dit aux organisateurs lors de la réunion de préparation : « Arrêtez-nous si ça dérape. » Il y aura assurément une présence que vous ne pouvez ressentir qu'en temps réel.
De quel genre de choses allons-nous parler ?
La réponse est... Tranquilo ! Ne vous précipitez pas !
Je vous attends le jour J.
Le blog est ici :
