Ce que nous refusons de construire

Un cabinet se juge à ce qu’il construit. Nous pensons qu’il se juge au moins autant à ce qu’il refuse.

Voici notre liste. Chaque ligne correspond à un projet qu’on nous a proposé, avec un budget, et que nous avons décliné. Nous la publions parce qu’un client a le droit de savoir, avant de nous appeler, où nous allons lui dire non.

Les quatre refus

Une plateforme dont l’usage n’est pas prouvé.

La demande arrive toujours dans les mêmes termes : « on voudrait une plateforme où tout serait centralisé ». Le mot est confortable parce qu’il ne désigne rien. Il permet de reporter la question difficile — qui l’ouvre, le matin, et pour faire quoi ?

Nous posons cette question. Si la réponse est une personne, une tâche, une fréquence, nous construisons. Si elle commence par « tout le monde pourra », nous ne construisons pas — « tout le monde » n’est le nom de personne. Un outil que tout le monde peut ouvrir est un outil que personne n’a la responsabilité d’ouvrir.

Le mode de défaillance est connu : six mois de développement, une belle interface, trois utilisateurs le premier mois, zéro le sixième — et le travail réel qui continue dans les mails et les tableurs, parce qu’il n’a jamais attendu qu’une plateforme lui donne la permission d’exister.

Un tableau de bord que personne ne regardera.

Celui-ci est le plus tentant, pour nous comme pour vous. C’est joli, ça se livre vite, ça se montre en comité de direction, et ça donne le sentiment très agréable d’avoir repris le contrôle.

Nous ne posons qu’une question avant de l’accepter : quelle décision change si ce chiffre passe au rouge ?

Si personne ne sait répondre, l’indicateur est une décoration. Il sera consulté trois fois la première semaine, jamais la troisième, et il finira sur un écran mural que plus personne ne voit. Pire : il rassure. Il donne l’impression que l’entreprise est mesurée, ce qui retarde d’autant le jour où quelqu’un ira vraiment regarder le système.

L’automatisation d’un processus qu’il faut d’abord supprimer.

C’est notre refus le plus fréquent, et le plus mal reçu.

On nous montre une tâche pénible et répétitive. Quelqu’un recopie chaque matin des lignes d’un export vers un second fichier. Trente minutes par jour, cent quinze heures par an. La demande est logique : automatisez-la.

Nous demandons ce que devient ce second fichier. Il alimente un rapport. Nous demandons qui lit le rapport. Silence. Puis : « il est envoyé à la direction régionale ». Nous appelons la direction régionale. Le rapport n’est plus lu depuis dix-huit mois — la personne qui le demandait est partie.

Automatiser cette recopie aurait été un excellent travail d’ingénierie au service de rien. Nous aurions livré, facturé, et la maison aurait payé à vie l’entretien d’un tuyau qui ne va nulle part. La bonne intervention coûtait un mail et douze minutes.

C’est le piège le plus profond du métier : une automatisation réussie rend le processus inutile invisible. Il ne coûte plus de temps humain, donc plus personne ne le remet en cause. Vous avez rendu permanent ce qui serait mort tout seul.

La séquence est toujours la même : supprimer, simplifier, puis seulement automatiser. On ne bétonne pas une route qui mène à un champ vide.

De l’IA posée sur des données fausses.

Le raisonnement se tient : nous avons beaucoup de données, l’IA sait les exploiter, donc mettons de l’IA. Il manque une étape. Ces données sont-elles vraies ?

Dans la plupart des maisons que nous regardons, la réponse est non — et pas un peu non. Le même client existe sous trois raisons sociales. Un champ « statut » contient onze valeurs pour désigner quatre états. La date de livraison est parfois la date promise, parfois la date réelle, selon qui a saisi.

Un humain absorbe cela. Il sait que « LIVRE » et « livré » sont la même chose. Il corrige en lisant, sans même s’en apercevoir. Un modèle, lui, ne corrige pas : il apprend le bruit, et il vous le restitue avec une assurance parfaite et une phrase bien tournée.

C’est ce qui rend l’erreur coûteuse. Un tableur faux se voit — le chiffre « fait bizarre ». Une réponse d’IA fausse ne fait pas bizarre. Elle fait professionnelle. Vous n’avez pas construit un outil d’aide à la décision : vous avez construit une machine à donner de l’aplomb à vos erreurs.

Ce que ces refus ont en commun

Relisez la liste. Chacun de ces projets est faisable. Chacun a un budget, un client demandeur, une technologie disponible. Aucun n’est un défi technique.

Et chacun est une manière de bâtir sur un terrain qu’on n’a pas regardé.

C’est le seul point commun, et c’est aussi la seule raison pour laquelle nous savons dire non : nous commençons par le dessin. Une fois le système posé sur la table, ces quatre projets se disqualifient d’eux-mêmes. On voit que la plateforme n’a pas d’utilisateur, que l’indicateur n’a pas de décision, que le flux n’a pas de destination, que la donnée n’a pas de source unique. Il n’y a rien de courageux à refuser. Il suffit de regarder.

La chute

Nous savons ce que ces refus nous coûtent. Des missions perdues, des budgets qui partent ailleurs, et parfois un client qui va faire construire chez quelqu’un d’autre exactement ce que nous venions de déconseiller. Nous n’en gardons pas d’amertume : ce projet se serait mal passé chez nous, et il se passera mal chez eux.

Mais mettez un instant les deux colonnes en face.

D’un côté, un cabinet qui vous vend ce que vous demandez : six mois, un budget à six chiffres, un objet conforme au cahier des charges, une facture d’entretien à vie, et un problème intact — puisque personne n’a regardé le système.

De l’autre, une conversation de deux heures au terme de laquelle quelqu’un vous dit : ceci ne doit pas être construit, voici pourquoi, et voici les trois choses qui, elles, valent la peine.

Dire non à un projet est le service le plus rentable que nous rendions à un client. C’est aussi le seul que personne ne pense à demander.