Quand un modèle cesse de tenir
Il y a un moment étrange, silencieux, où l’on s’aperçoit qu’une règle non écrite ne vaut plus. Pas parce que quelqu’un l’a contestée courageusement, mais parce que la réalité a cessé de coopérer.
Dans le conseil IT, ce moment, à mon avis, est maintenant.
Pendant des années, on a vécu dans un pacte confortable : tu me payes le temps, j’essaie. On l’appelait time & materials, staff augmentation, body rental. Différents noms, même idée. Tu achetais des heures humaines et tu espérais qu’elles deviennent quelque chose d’utile. Parfois ça arrivait, parfois non. Dans les deux cas, tu payais.
Et ce n’était pas que ça marchait parce que c’était juste. Ça marchait parce que ça semblait la seule façon possible. Le logiciel est complexe, estimer est dur, les exigences changent, la technologie aussi. Alors on s’est raconté que le temps était une bonne approximation de la valeur.
Puis l’IA est arrivée et, sans demander la permission, elle a rendu cette fiction beaucoup plus dure à tenir.
Le mensonge confortable du time & materials
Le time & materials, dépouillé de ses mots élégants, est surtout une chose : un mécanisme de transfert du risque.
Le risque de mal estimer, de découvrir des soucis techniques, de gérer un scope qui s’élargit, de réaliser tard que l’idée initiale ne tient pas. Dans le modèle à l’heure, ce risque finit presque toujours sur le client. Le prestataire « met les gens », le client paie l’exploration, même quand l’exploration mène à une impasse.
Décrit ainsi dans d’autres secteurs, ça paraît absurde. Imagine un plombier qui facture les heures sans promettre que l’eau coulera. Ou un chirurgien payé à la minute, indépendamment du résultat.
Et pourtant, en IT, c’était normal. Mieux : attendu. Si un client demandait des garanties, il était souvent étiqueté « compliqué ». Si un prestataire proposait un prix fixe, il paraissait naïf ou dangereux.
La justification était toujours la même : « le logiciel, c’est différent ». C’est vrai en partie. Mais conclure que le seul modèle honnête est de facturer le temps a toujours été un saut logique.
La vérité un peu triste, c’est que ça arrangeait tout le monde, à court terme. Beaucoup de clients n’avaient pas la compétence interne pour distinguer qualité et inefficacité. Et beaucoup de prestataires, soyons honnêtes, ont appris à bien vivre dans ce monde. Parce que le temps est mesurable, la valeur non. Et quand tu ne sais pas mesurer la valeur, tu finis par acheter ce que tu sais compter.
Le problème, c’est que les incitations deviennent étranges. Parfois inversées. Si tu es plus lent, tu factures plus. Si tu résous en deux heures au lieu de vingt, tu « laisses sur la table » dix-huit heures. Personne ne le dit aussi ouvertement, mais le système poussait dans cette direction.
L’IA entre en scène et raccourcit les heures
Puis, en très peu de temps, certaines activités quotidiennes ont commencé à s’effondrer.
Boilerplate, intégrations répétitives, scaffolding de migrations, tests générés, doc initiale, transformations de données. Pas tout, pas toujours, pas parfaitement. Mais assez pour changer l’arithmétique.
Et arrive le point qui met le modèle en crise : si hier une intégration « valait » 80 heures et aujourd’hui demande 15 avec assistance IA, qu’est-ce que tu factures ?
Si tu factures 15 heures, ton chiffre baisse drastiquement à résultat égal.
Si tu factures 80 heures quand même, tu fais quelque chose qui ressemble beaucoup à une fraude, même appelée « buffer », « contingence », « gestion du risque ». Tout le monde ne le vit pas comme ça, mais le sentiment est dur à ignorer.
D’où trois réactions, toutes fragiles :
Certains cachent l’usage de l’IA.
D’autres l’interdisent, moins pour la qualité que pour protéger le modèle.
D’autres l’utilisent et gardent les prix à l’heure, retenant le gain de productivité.
Le point, c’est que cette fenêtre se referme. L’arbitrage entre « combien il fallait à un humain » et « combien il faut à une personne avec IA » s’élargit trop. Tôt ou tard, côté client, quelqu’un fera ses comptes. Ou comparera des prestataires. Ou se demandera pourquoi la même chose, aujourd’hui, coûte autant qu’il y a deux ans.
Si le code coûte moins, que reste-t-il à vendre ?
Voilà la question qui, à mon avis, sépare ceux qui survivent de ceux qui se figent.
Parce que si l’IA t’aide à écrire code, tests et doc plus vite, on pense naturellement : « ok, mon travail vaut moins ».
Je n’en suis pas du tout convaincu. Peut-être qu’une partie du travail vaut moins, la plus mécanique. Mais cette réduction fait émerger le reste, ce qui a toujours été de la valeur et qu’on emballait dans les heures.
Ce que les clients cherchent vraiment, ce n’est pas le code. C’est un résultat.
Un produit qui marche.
Un risque réduit.
Une capacité nouvelle.
Une décision bien prise.
Et il y a des zones où l’IA, du moins pour l’instant, ne remplace pas vraiment le conseil. Elle l’amplifie.
Comprendre le problème, pas seulement les exigences
Les exigences techniques sont souvent des symptômes. Le vrai problème est plus dessous : processus, contraintes, gens, politique interne, incitations. Parfois aussi des peurs non dites.
Comprendre cela demande de l’écoute, du contexte, et un brin de courage à dire des choses inconfortables.
Prendre des décisions difficiles et irréversibles
Architecture, build vs buy, modèle de données, posture sécurité. Des décisions qu’on paye pendant des années.
L’IA peut proposer des options, mais bien choisir, en assumant, c’est autre chose.
Prendre la responsabilité
C’est le plus central, à mon avis.
L’IA ne peut pas être appelée à 3 h du matin quand quelque chose tombe. Elle ne peut pas mettre son visage devant le board. Elle ne peut pas porter la responsabilité juridique ou réputationnelle.
Un prestataire, oui. Et cette responsabilité devient aujourd’hui une composante explicite de la valeur.
Naviguer la compliance et les contraintes réelles
Pas seulement « ce qu’on peut construire », mais « ce qu’on peut construire sans s’attirer d’ennuis ».
RGPD, NIS 2, Accessibility Act, Cyber Resilience Act, AI Act. En Europe, il devient de plus en plus clair que le logiciel n’est pas qu’un projet, c’est un produit avec des obligations.
Le pricing à la valeur : tout le monde en parle, peu le pratiquent
Le pricing à la valeur n’est pas une nouveauté. Pourtant, dans le conseil IT, il est resté souvent un idéal lointain.
Pourquoi ? Parce qu’il exige une chose que le T&M te permet d’éviter : prendre le risque.
Vendre à la valeur, c’est vendre des résultats. Et si tu vends des résultats, tu dois être prêt à dire « si on n’y arrive pas, on en répond ».
Ce n’est pas qu’un changement de tarif. C’est un changement d’identité.
Cela veut dire arrêter de vendre des « jours-homme » et commencer à vendre, par exemple, « une intégration fonctionnelle entre CRM et ERP, avec monitoring, logging, tests et critères d’acceptation clairs ».
Cela veut dire bâtir des méthodes pour estimer et gouverner l’incertitude, plutôt que la transférer.
Cela veut dire investir dans des processus, de la qualité, des spécifications, et oui, dans l’IA aussi, mais de façon transparente.
Et un doute me reste : peut-être beaucoup d’entreprises n’ont-elles pas peur de l’IA. Elles ont peur de ne plus pouvoir cacher l’inefficacité derrière un timesheet.
Le vrai obstacle : la peur de la responsabilité
J’ai parlé à beaucoup de monde du secteur cette dernière année. Presque tout le monde dit que le modèle à la valeur est « le futur ». Peu l’appliquent vraiment.
Et je ne crois pas que ce soit seulement par complexité commerciale. Je crois que c’est par peur.
Le T&M est confortable parce qu’il te protège. Si ça tourne mal, tu peux toujours dire « vous avez demandé ça », « on a suivi les exigences », « on a mis les heures ». La responsabilité du résultat se dissout.
Quand tu vends un outcome, cette protection disparaît. Si ça ne marche pas, c’est ton problème. Si ce n’est pas conforme, tu corriges. Si l’impact business n’arrive pas, tu dois l’expliquer.
C’est inconfortable. Mais c’est aussi, enfin, honnête.
Une note pour ceux qui achètent du conseil
Ce n’est pas que la faute des prestataires. Les acheteurs aussi ont contribué au système.
Si tu choisis tes partenaires en regardant surtout le tarif journalier, tu dis au marché que ce qui t’intéresse est le coût unitaire, pas le résultat. Et tu ne devrais pas être surpris de recevoir de la conformité, pas du courage. De la présence, pas de la responsabilité.
Dans le monde post-IA, à mon avis, bien acheter, c’est faire un saut :
Demander des outcomes mesurables, même s’ils ne sont pas parfaits.
Payer plus celui qui prend du risque et y met de la transparence.
Cesser d’exiger des spécifications kilométriques comme forme de contrôle, et commencer à décrire problème, contraintes, critères de succès.
Bâtir un minimum de compétence interne pour évaluer la qualité, sinon tu reviendras toujours à acheter des heures, la seule chose que tu sais compter.
On entre dans une économie de la confiance
Un effet collatéral de l’IA me paraît énorme : produire est devenu moins cher, vérifier est devenu plus cher.
Aujourd’hui, n’importe qui peut générer du code, de la doc, des diagrammes, des rapports « crédibles ». Le problème n’est pas d’obtenir un output. C’est de savoir si cet output est fiable, sûr, maintenable, conforme.
La question change donc.
Ce n’est plus « tu sais faire ? ». C’est « puis-je faire confiance à ce que tu me livres ? »
Et la confiance, ça ne s’automatise pas. Ça se construit avec un track record, de la transparence, de la responsabilité, la capacité d’admettre une erreur et de la corriger.
En ce sens, le pricing à la valeur est aussi un signal : quand un prestataire accepte d’être payé pour un résultat, il dit qu’il croit assez en son travail pour y mettre sa peau.
Une confession, parce que je suis dedans aussi
Ici, on a facturé à l’heure pendant des années. C’était normal. C’était simple. C’était, d’une certaine manière, rassurant.
Puis l’IA a vraiment commencé à accélérer le travail. Et on s’est trouvé devant un choix que beaucoup vivent maintenant : faire semblant de rien, ou changer.
Changer fatigue. Ça t’oblige à repenser offres, contrats, processus, et la culture interne. Ça t’oblige à te demander dans quoi tu es bon et dans quoi tu ne l’es pas. Ça t’oblige à dire des non.
Je ne sais pas si on fera tout parfaitement. Probablement pas.
Mais une chose me semble claire : le time & materials n’est pas « mort » parce que l’IA écrit du code. Il est mort parce que l’IA a rendu impossible de continuer à faire semblant que le temps est une mesure honnête de la valeur.
Et peut-être, à dire vrai, c’est une bonne nouvelle. Pas parce que ce sera facile, mais parce que ça oblige tout le monde à revenir à ce qu’on aurait dû vendre depuis toujours : résultats, responsabilité et confiance.
Ce qu'il faut retenir
Le T&M est un mensonge confortable : le temps était un proxy de la valeur, pas la valeur.
L’outcome-based pricing, c’est facturer ce que tu livres (time-to-market, SLA, taux de défauts) et assumer le risque si ça n’arrive pas.
Le vrai obstacle n’est pas le client : c’est la peur de la responsabilité interne au prestataire.
Les PME du conseil ont une fenêtre concurrentielle : les grands cabinets ont des organisations bâties sur le T&M, ils ne pivotent pas vite.
Acheter du conseil, c’est arrêter de demander « combien coûte une journée » et commencer à demander « combien coûte que le problème X soit résolu avec ces paramètres ».
Questions & réponses
Pourquoi le time & materials ne tient-il plus dans le conseil IT ?
Parce que le temps a cessé d’être une bonne approximation de la valeur. Pendant des années, on a vendu des heures humaines en espérant qu’elles deviennent quelque chose d’utile — non parce que c’était juste, mais parce que ça semblait la seule façon de valoriser la complexité. Avec l’IA qui réduit la corrélation entre heures passées et résultat, la fiction s’effondre : le client paie 40 heures à qui en a employé 4 en substance, et 10 heures à qui livre moins que celui qui en a employé 40.
Que reste-t-il à vendre si on ne vend plus le temps ?
Des résultats, de la responsabilité, de la confiance. Outcome-based pricing : tu factures ce que tu livres (time-to-market, SLA, taux de défauts, niveau de support), pas ce que tu mets pour le livrer. Cela veut aussi dire prendre le risque : si l’outcome n’arrive pas, tu paies. C’est un contrat plus adulte des deux côtés.
Le client est-il prêt à ce modèle ?
Souvent non, parce qu’il est éduqué par des décennies de T&M à raisonner en jours-homme. Mais le client ne veut pas vraiment des « jours-homme », il veut un problème résolu. Traduire la conversation commerciale de « combien coûte une journée » à « combien coûte que le problème X soit résolu avec ces paramètres » est un travail de vente, pas de marketing. Qui le fait bien se différencie.
Qu'est-ce qui change pour les consultants IT plus petits ?
Ils peuvent faire partie des premiers à changer de modèle. Les grands cabinets ont des organisations bâties sur le T&M et une transition lente. Une PME du conseil qui price à l’outcome, prend le risque et garde des marges saines sur un output réduit en heures a une fenêtre concurrentielle qui ne durera pas pour toujours. Le coût : accepter que certaines missions seront plus risquées — le levier : pour la même qualité de résultat, le client paiera moins en valeur absolue mais plus en marge horaire pour le consultant.
L'auteur
