La semaine dernière, j’ai passé une heure au téléphone avec un assureur qui veut refondre son site web et son application mobile : déclaration de sinistre, gestion des contrats, envoi de pièces justificatives, et la bascule vers un conseiller quand le parcours déraille, ce qui, dans la gestion des sinistres, arrive la plupart du temps. Un vrai projet, avec de vrais utilisateurs.
Au bout de dix minutes, mon interlocuteur m’a demandé à voir mon logiciel.
Pas une architecture de référence, pas une étude de cas : une démonstration du produit. Il voulait des écrans, une console d’administration, des niveaux de licence et la feuille de route de l’an prochain.
Je lui ai expliqué qu’il n’y en avait pas. Nous avons passé les cinquante minutes restantes à ne pas nous comprendre.
Le malentendu n’a jamais été technique. Il savait ce dont l’IA est capable. Il ignorait ce qu’on lui demandait de signer.
Ce qu’il croyait acheter
Il ne cherchait pas à compliquer les choses. Il faisait son travail comme son entreprise l’a toujours fait. Ce n’est pas la même chose, et l’argument est bien plus difficile à contrer.
La liste d’achats qu’il avait en tête se présentait ainsi :
- Un logiciel qui construit le site web
- Un logiciel qui gère les contenus
- Un logiciel qui gère le traitement des sinistres
- Un logiciel qui relie les trois
Quatre produits, sans doute trois éditeurs, et autant de feuilles de route qui appartiennent à d’autres.
C’est le modèle qu’il connaît. Surtout, sa direction des achats est entièrement bâtie autour de ce modèle, et ce n’est pas un mardi après-midi, sur la foi d’un fournisseur qui lui assure que le monde a changé, qu’il va le remettre en cause.
En un coup d’œil : deux façons d’acheter le même résultat
| Acheter une licence | Acheter un développement |
|---|---|
| Comparer des grilles de fonctionnalités | Décrire le résultat attendu |
| Un produit et une version identifiés | Rien à nommer tant que rien n’existe |
| Trois références sur un déploiement identique | Personne n’utilise exactement la même chose que vous |
| La feuille de route appartient à l’éditeur | La feuille de route vous appartient |
| Tarif par licence utilisateur et par an | Tarif selon le travail effectué, par exécution |
La première colonne est un exercice de comparaison. La seconde exige de formuler ce que vous voulez avant que rien n’ait été construit. C’est un tout autre savoir-faire, et nettement moins confortable.
La phrase qui a mis fin à l’appel
Je lui ai donc fait une proposition que je jugeais généreuse : envoyez-moi votre cahier des charges, même sommaire. Un document Word avec quelques puces. Une capture d’écran de la page sinistres actuelle, annotée de flèches rouges. J’ai connu pire comme point de départ.
Sur cette base, je reviens avec quelque chose de cliquable, pas avec des diapositives.
Sa réponse m’a poursuivi toute la semaine.
Je ne sais pas ce que je veux. Je veux que vous arriviez avec un logiciel.
Le client, au téléphone, août 2026. Je tais son nom et celui de son entreprise. Cette année, j’ai entendu d’autres acheteurs prononcer des variantes très proches de cette phrase.
Le prix n’a jamais été évoqué, pas une seule fois, et j’aurais dû y voir un signal plus tôt. Le problème était ailleurs : son organisation n’a aucun moyen d’approuver une offre qui ne prend pas la forme d’un produit.
Un problème d’achats, et non d’IA
L’essentiel de ce que je lis sur la lente adoption de l’IA dans les secteurs traditionnels met en cause la technologie. Les modèles hallucinent. La conformité bloque tout. Les données sont en désordre et, reconnaissons-le, c’est le plus souvent le cas.
En soixante minutes, rien de tout cela n’est venu sur la table. Pas une fois.
Le blocage était purement commercial. Il sait acheter une licence. Il n’a ni processus ni vocabulaire pour acheter de la capacité de développement.
Ce sont deux muscles distincts de l’organisation. Acheter une licence, c’est comparer des choses qui existent déjà, un exercice dans lequel la plupart des entreprises sont passées maîtres en quinze ans. Acheter un développement, c’est décrire un résultat, puis confier à quelqu’un le soin de le produire. Ce second muscle s’est atrophié pendant que chacun perfectionnait le premier, et personne ne s’en est aperçu : jusqu’à récemment, rien n’obligeait à s’en servir.
Quand on ne sait acheter qu’en comparant, un fournisseur qui refuse la comparaison passe pour un risque plutôt que pour une opportunité, et, au regard des critères sur lesquels il est jugé, l’acheteur n’a pas tort de le voir ainsi.
Sa prudence a ses raisons
Il serait commode de dépeindre ce client en dinosaure. Je m’en garderai, parce qu’il n’en est pas un.
Le progiciel apporte des garanties bien réelles. Quelqu’un d’autre en assure la maintenance et corrige les failles de sécurité à deux heures du matin sans vous consulter. D’autres clients utilisent le même code, si bien que la plupart des bugs sont débusqués par d’autres que vous. Et en cas de problème, il y a un contrat à invoquer, avec un nom au bas de la page.
Le développement spécifique a derrière lui une longue histoire d’échecs, abondamment documentée. Quiconque a passé vingt ans dans l’informatique d’entreprise a vu un système maison devenir un fardeau impossible à maintenir, et survivre à trois DSI. Quelqu’un a payé cette leçon, souvent de son poste, et la prudence qu’il en a héritée est la trace d’un événement bien réel, pas un trait de caractère.
La question n’est donc pas de savoir si cette prudence était justifiée. Elle l’était. Reste à savoir si elle vise toujours juste.
Le coût du développement s’est effondré, tout est là
Le coût du développement s’est effondré, et la plupart des acheteurs n’en ont pas pris la mesure. Personne ne les a prévenus. Les éditeurs avec lesquels ils traitent n’ont aucun intérêt à le faire, et la presse spécialisée s’intéresse aux modèles plutôt qu’à la facture.
J’ai raconté dans cette collection, dans l’article sur l’apocalypse de l’emploi, un week-end où j’ai mis en service, seul, deux agents opérationnels qui, dix-huit mois plus tôt, auraient mobilisé une petite équipe pendant quelques semaines. Ce n’était pas un coup d’éclat. C’est désormais l’ordinaire du métier, et cela se vérifie dans toutes les fonctions pour lesquelles nous avons développé.
Quand développer coûte peu, acheter un produit rigide pour s’en dispenser n’est plus le choix prudent. C’est seulement le plus familier.
Cela change l’équation pour toute une catégorie d’applications. Pas pour toutes. Un système central de gestion des contrats n’en fait pas partie, et je ne prétendrai pas le contraire. Mais un portail sinistres se résume pour l’essentiel à de la saisie, de la capture de documents, un suivi d’état, l’application de règles, une file d’exceptions et un relais humain, autant de briques que nous avons déjà livrées ailleurs. Il en va de même pour la plupart des besoins que ses quatre produits devaient couvrir.
Ce qui n’a pas baissé
Cela commence à ressembler à un argumentaire commercial, je l’entends bien. Voici donc l’autre versant.
Je ne vais pas survendre ce modèle, et surtout pas dans l’assurance.
Les secteurs réglementés restent soumis à des contraintes qu’aucun modèle ne fait disparaître :
- Les règles de localisation des données et de protection de la vie privée ne s’assouplissent pas parce que le code a été livré plus vite
- La traçabilité d’une décision d’indemnisation est une obligation légale, pas une fonctionnalité
- La troisième année, il faut toujours quelqu’un pour répondre du système, quand celui qui l’a construit est passé à autre chose
- C’est l’intégration avec un système de gestion des contrats vieux de trente ans qui fait réellement échouer ces projets, et le code généré ne corrige pas une interface mal conçue
La vitesse est réelle. Le travail de gouvernance, lui, ne s’est pas réduit pour autant. Il compte même davantage, car le même nombre de relecteurs doit examiner chaque semaine un volume plusieurs fois supérieur. Quiconque affirme le contraire à un assureur lui vend un échec livré en un temps record.
L’appel d’offres, là où meurt l’affaire
Le symptôme le plus tangible de tout cela, c’est la paperasse.
Un appel d’offres type, pour un projet comme le sien, pose quatre questions auxquelles je ne peux pas répondre honnêtement.
Les quatre questions, et la réponse honnête à chacune
| Ce que demande l’appel d’offres | La réponse honnête |
|---|---|
| Nom et version de la plateforme | Aucun nom de plateforme à donner |
| Coût de licence par utilisateur et par an | Les licences utilisateurs sont gratuites. Les exécutions sont facturées à l’usage |
| Trois références en production, même développement | Aucun de mes développements n’est identique au vôtre |
| Feuille de route produit sur les 24 prochains mois | La feuille de route est la vôtre, pas la mienne |
La seconde colonne est la plus honnête, et elle fait très mauvaise impression. Prenez la ligne sur le prix. Ce que j’entends par là, c’est qu’ouvrir un compte à quarante personnes coûte autant que l’ouvrir à quatre, et que la facture suit ce que le système exécute réellement. Pour un acheteur dont tout le modèle de coûts repose sur l’effectif multiplié par un prix annuel par licence, ce n’est pas une remise : c’est une catégorie pour laquelle il n’a aucune case. Relisez le reste de la colonne avec les yeux d’un responsable des achats, et chaque réponse semble évasive. Un processus conçu pour écarter le flou finit par écarter la meilleure offre, et l’acheteur ne le saura jamais, car le fournisseur incapable de remplir le formulaire cesse tout bonnement de répondre.
L’intelligence de l’acheteur n’est pas en cause. Le formulaire remplit exactement la fonction pour laquelle il a été conçu, et il la remplit bien, sur un marché qui ne ressemble plus à celui pour lequel il a été écrit.
J’ai changé ma façon de vendre
Voilà pour le diagnostic, qui ne coûte rien. Changer, en revanche, m’a coûté ceci.
J’ai arrêté d’expliquer. Avec cet acheteur, l’explication ne fonctionne pas. L’IA ne le déroute pas : il lit la même presse que tout le monde. Ce qui le laisse perplexe, c’est ce qu’il est censé présenter à son comité d’approbation.
J’ai donc changé l’ordre des opérations :
- Je ne vante plus des capacités : j’apporte un objet concret
- Avant le deuxième rendez-vous, je construis une version sommaire de leur outil, avec leur logo et leur véritable parcours de déclaration de sinistre
- Je la mets entre leurs mains et je les laisse cliquer
- Puis je leur demande ce qui ne va pas
Je ne m’y attendais pas, mais les reproches tiennent lieu de spécifications. Un acheteur incapable de rédiger un cahier des charges sait toujours dire ce qui ne va pas dans ce qu’il voit à l’écran, et il le fait en détail, spontanément, en quatre-vingt-dix secondes environ. Je ne connais pas de chemin plus court entre « je ne sais pas ce que je veux » et un périmètre que quelqu’un acceptera de signer.
Cela me coûte quelques jours par prospect, dont une partie perdue sur des affaires qui n’auraient jamais abouti. Je reste convaincu que c’est préférable à la conversation abstraite, qui coûte les mêmes quelques jours et se termine par un rendez-vous de suivi.
Où je pourrais me tromper
Je vends ce modèle. Raison de plus pour relativiser mon analyse, pas pour l’accepter.
L’objection évidente : son instinct le protège de moi. Si le développement tourne mal, il n’a ni éditeur à attaquer en justice, ni autre client utilisant le même code avec qui comparer. Je lui réponds par un périmètre écrit, une approbation préalable pour tout ce qui publie ou engage une dépense, et un code qui lui reste acquis à la fin. Je crois à ces réponses. Mais c’est moi qui les ai conçues, pas lui qui les a éprouvées, et à sa place je les trouverais sans doute un peu légères.
Il existe aussi un scénario dans lequel le progiciel absorbe tout cela et l’avantage du développement s’efface. Les grandes plateformes intègrent en ce moment même ces mêmes schémas d’agents à leurs produits. Si elles y parviennent, il faudra admettre qu’il avait raison d’attendre et que j’étais parti trop tôt. Cela m’est déjà arrivé. Cela se reproduira sans doute.
À faire dès lundi
Trois choses, valables quel que soit le côté de la table où vous êtes assis. J’applique désormais la troisième moi-même, et c’est ainsi que je sais qu’elle est plus difficile qu’il n’y paraît.
Reprenez le dernier appel d’offres logiciel que vous avez lancé et comptez les questions qui partent du principe que la réponse existe déjà sous forme de produit. Ce nombre, c’est votre filtre, et il est sans doute plus élevé que vous ne l’imaginez.
Demandez à un fournisseur un prototype fonctionnel avant de lui demander une proposition. Payez-le s’il le faut. Quelques jours de développement coûtent moins cher qu’une procédure de sélection qui vous enferme dix-huit mois dans le mauvais choix.
Écrivez ce que l’outil doit vraiment faire, avec vos mots, même maladroitement. Cette version maladroite vaut davantage qu’un cahier des charges soigné, parce qu’elle dit honnêtement ce que vous ignorez encore.
Trois convictions que je suis prêt à défendre
D’abord, le vocabulaire. Dans les entreprises de taille intermédiaire, ce qui freine aujourd’hui l’adoption n’est pas la qualité des modèles. C’est que les acheteurs n’ont de mots que pour les licences.
Ensuite, la direction. Dès qu’une entreprise découvre qu’elle peut commander un développement pour le prix d’un renouvellement de licence, elle ne revient pas à la licence. Ce constat vient de nos propres comptes clients et non d’une enquête : voyez-y une tendance qui revient sans cesse dans ce que j’observe, pas une loi.
Enfin, le coût de l’attente. L’acheteur qui patiente jusqu’à ce que tout cela se vende sur catalogue paie ces années d’attente, puis paie une seconde fois le produit à son arrivée.
Ne demandez plus la démo. Demandez le prototype.
Il voulait que j’arrive avec un logiciel. Ce que je peux apporter, c’est une fonction de son parcours sinistres, qui tourne sur ses propres données dès la première semaine, parce que c’est le périmètre de la prise en main et qu’elle se déroule de la même manière pour chaque compte. La promesse est plus modeste que celle qu’il réclamait, et bien plus facile à vérifier pour lui avant de s’engager sur quoi que ce soit.
Ouvrez un compte et lancez un module sur une marque, ou réservez une démo pour voir la plateforme à l’œuvre sur vos propres chiffres plutôt que sur un espace de démonstration.
Écrit fin août 2026, au sortir d’un appel qui s’est mal passé. J’y reviendrai dans six mois pour relever mes erreurs, comme je l’ai fait pour l’article sur l’apocalypse de l’emploi. La suite sera envoyée aux abonnés de ma lettre d’information.
