Il y a une phrase qui, dans le conseil — au moins chez nous —, sonne presque comme un blasphème. Une de ces choses que vous pensez en regardant la énième réunion se transformer en catalogue de demandes, mais que vous ne dites pas. Parce que ça ne se fait pas, parce que « la relation client », parce que le commercial vous foudroie du regard et que quelqu’un vous rappelle qu’« on est là pour satisfaire les besoins ».
Et pourtant.
Le client a tort.
Pas toujours, évidemment. Pas sur tout. Mais bien plus souvent qu’on aime l’admettre. Et je me demande si le vrai problème n’est pas le client lui-même, mais le mensonge poli qu’on lui raconte depuis des années. Celui du « le client a toujours raison ». Un mensonge qui dans le logiciel italien a fait des dégâts qu’on n’arrive même pas à compter, parce que les échecs ont rarement une pancarte « échec » dessus. D’habitude ils sont plus silencieux. Ce sont des projets qui finissent en production et que personne n’utilise. De l’argent brûlé sur des choses qui n’améliorent rien. Des nuits longues de gens qui savaient que ça partait mal, mais qui n’avaient pas l’espace, ou la permission, de le dire.
C’est un texte un peu méchant, oui. Je ne vous demande pas d’être d’accord. Je vous demande juste d’être honnête, le temps de cette lecture.
Le oui qui tue les projets
J’ai vu mourir plus de projets pour un oui que pour un non.
Le mécanisme est presque toujours le même, et c’est précisément pour ça qu’il fait peur. Le client demande quelque chose. Vous le savez, vous le sentez, vous le voyez dans les détails : c’est faux techniquement, ou économiquement, ou tout simplement comme direction. Mais vous dites oui quand même.
Vous dites oui parce qu’il y a un contrat. Parce qu’il y a une relation à protéger. Parce qu’« on règlera ça plus tard ». Parce que la poignée de main est déjà donnée et que revenir en arrière ressemble à une défaite. Parce que dire non est inconfortable, demande des arguments, demande de l’énergie, et surtout du courage.
Et alors le projet ne meurt pas d’un coup. Il meurt un oui à la fois.
Chaque oui ajoute une feature dont personne ne se servira. Chaque oui repousse un bout de deadline ou comprime un bout de qualité. Chaque oui rend l’architecture un peu plus fragile et le code un peu plus tordu, jusqu’à ce que ce que vous construisez ne ressemble plus à un produit, mais à un compromis stratifié.
À la fin, vous livrez un logiciel qui fait cent cinquante choses, aucune bien, et le client vous regarde et dit : « ce n’est pas ce que je voulais ».
Et c’est là que ça brûle, parce que d’une certaine façon il a raison. Ce n’est pas ce qu’il voulait. C’est ce qu’il a demandé. Deux choses différentes.
Et notre métier, le vrai, n’est peut-être pas d’exécuter des ordres. Il est de reconnaître la différence.
Catalogue des horreurs (toutes vraies, hélas)
Ce qui suit est vrai. Les noms sont changés, pas les dynamiques. Et si vous pensez « j’en ai vu un identique », vous n’êtes pas seul.
La GED infinie
Une entreprise moyenne demande une GED. Jusque-là tout va. Puis, en cours de développement, chaque service ajoute des exigences. Les RH veulent le module congés, le marketing veut le tableau de bord, la compta veut l’intégration avec l’expert-comptable, et chacun se croit le centre du monde.
Personne n’a le pouvoir de dire stop, parce que chaque service est un « client interne » qui « a raison ». Résultat : dix-huit mois de développement, un produit qui fait tout mal, et après la livraison l’entreprise continue à utiliser Excel. Qui, dans son coin, au moins, ne trahit pas.
L’appel d’offres photocopié
Une commune doit numériser un service. L’appel d’offres est rédigé en copiant celui d’une autre commune, peut-être trois fois plus grande, aux besoins complètement différents. On y met des exigences qui sonnent bien sur le papier, mais qu’aucun citoyen n’utilisera jamais.
Celui qui remporte le marché le sait souvent. Mais l’appel d’offres est l’appel d’offres. Donc on construit exactement ce qui est écrit. On livre, on recette, on coche les cases. La plateforme passe en ligne.
Six mois plus tard, le service est encore géré par téléphone.
Et le plus triste, c’est que, formellement, tout s’est bien passé.
L’app qui devait tout changer
Une administration locale veut une app mobile pour les citoyens. Le décideur est un élu qui a vu l’app d’une autre commune et la veut pareille. Pas d’analyse des besoins, pas de recherche utilisateur, rien. Juste : « je veux l’app ».
Le fournisseur la construit. Au lancement, quatre cents téléchargements. Trois mois plus tard, douze utilisateurs, employés de la commune compris.
L’élu fait sa conférence de presse et parle d’innovation. Le fournisseur encaisse et passe au suivant.
Et je n’arrive jamais à décider qui me met le plus mal à l’aise dans cette histoire.
Le restyling qui était une réécriture
Un client demande de « rafraîchir » le site. Le commercial vend un restyling. Lors de la première réunion opérationnelle, il apparaît que le site n’a pas de CMS, que la base de données est un fichier Excel, que les contenus n’existent pas et que « rafraîchir » signifie repenser toute la présence numérique.
Mais le devis est celui d’un restyling, la timeline est celle d’un restyling, et les attentes sont celles d’un restyling.
Tout le monde sait que ce n’est pas un restyling. Personne ne le dit.
Le projet zombie
Un projet devait durer six mois et entre dans sa troisième année. Il ne marche pas, il n’est pas utilisé, mais personne ne le ferme parce que le fermer reviendrait à admettre que c’était une erreur.
Le client continue à payer des change requests. Le fournisseur continue à facturer. Tous deux savent qu’il est mort. Tous deux font semblant qu’il est vivant.
Il n’échoue jamais officiellement. Il cesse simplement d’être cité en réunion, comme un oncle gênant dont on ne parle pas à table.
Pourquoi ça arrive vraiment
Ça arrive parce que notre secteur a un problème structurel avec la vérité.
Le modèle économique du conseil IT italien est bâti sur le oui. Vous gagnez les projets en disant oui. Vous gardez les clients en disant oui. Vous faites carrière en disant oui. Tout le système, des commerciaux aux chefs de projet jusqu’aux développeurs, est optimisé pour minimiser le conflit et maximiser la facturation à court terme.
Le hic, c’est que court terme et long terme sont en guerre.
Dire oui aujourd’hui, c’est presque toujours payer demain. Chaque feature en plus est de la dette technique. Chaque exigence acceptée sans analyse est une bombe à retardement. Chaque timeline comprimée pour faire plaisir à quelqu’un est une garantie d’heures sup, souvent non payées, et de qualité sacrifiée.
Et pendant ce temps, le client n’apprend jamais. Pas parce qu’il est bête, mais parce que personne ne lui dit que cette demande était fausse. Personne ne lui dit que cet appel d’offres était mal écrit. Personne ne lui dit que cette app ne servait à personne.
Entouré de gens qui acquiescent, le client continue à demander les mêmes mauvaises choses, et le cycle reprend.
Et c’est ici qu’arrive la partie qui dérange, parce qu’elle déplace la responsabilité.
Ce n’est pas la faute du client. C’est notre faute.
C’est la faute d’un secteur qui a renoncé à son rôle, celui de l’expert. Celui qui sait des choses que le client ne sait pas, et qui a le devoir, non le droit, de les lui dire.
Le non comme service
Le meilleur service que vous puissiez rendre à un client, c’est de lui dire non.
Non, cette feature ne sert à rien.
Non, cette timeline n’est pas réaliste.
Non, cet appel d’offres est mal écrit, et si on le suit à la lettre on construira une chose inutile.
Non, vous n’avez pas besoin d’une app.
Non, vous n’avez pas besoin d’IA.
Non, vous n’avez pas besoin d’un restyling. Vous avez besoin de vous arrêter et de comprendre ce que vous voulez vraiment faire.
Chaque non a un coût. Coût de la gêne, coût de la tension, coût de quelques coups de fil difficiles. Parfois, coût du projet.
Mais chaque non est aussi un acte de respect envers le client, parce qu’il le traite comme un adulte capable d’entendre la vérité, pas comme quelqu’un qu’il faut contenter pour la paix des ménages.
Les meilleurs clients que j’ai eus dans ma carrière sont ceux à qui j’ai dit le plus de non. Au début, ils se raidissent, c’est normal. Puis, si vous tenez et si vous argumentez calmement, il se passe une chose : ils comprennent que quand vous dites oui, on peut vous croire.
La confiance ne se construit pas sur l’accord continu. Elle se construit sur la sincérité.
Et la sincérité, dans notre secteur, est rare. Peut-être plus rare qu’un bon développeur. Peut-être plus rare qu’un projet livré à l’heure. Peut-être plus rare qu’un appel d’offres bien rédigé.
Un manifeste minimal, sans héroïsme
Je ne sais pas si c’est un manifeste, mais s’il en est un, il tient pour moi en trois lignes.
Ne dites pas oui quand vous savez que c’est non.
Ne construisez pas ce que le client demande si vous savez que ce n’est pas ce qui lui faut.
Et quand vous vous trompez — parce que vous vous tromperez et qu’on se trompera tous —, trompez-vous au moins en disant la vérité, pas en acquiesçant.
Le client n’a pas toujours raison. Mais il mérite toujours quelqu’un qui ait le courage de le lui dire.
Ce qu'il faut retenir
Chaque oui ajoute de la dette technique, comprime la qualité et prépare le « ce n’est pas ce que je voulais » final.
La confiance ne se construit pas sur l’accord continu, mais sur la sincérité : quand vous dites oui, on peut vous croire.
La sincérité, dans notre secteur, est plus rare qu’un bon développeur ou qu’un appel d’offres bien rédigé.
Questions & réponses
Pourquoi dire oui à tout au client tue-t-il les projets de conseil ?
Parce que le client formule souvent une solution là où il devrait formuler un problème. Dire oui à « je veux une app mobile » alors que le vrai problème est « mes commerciaux perdent du temps à remplir des rapports » revient à construire la chose correcte pour un mauvais problème. Le oui automatique livre le projet demandé, pas celui qui était nécessaire — et six mois plus tard c’est le consultant qui passe pour mauvais, pas le brief qui était faible.
Comment dit-on non de manière constructive ?
En séparant les morceaux. « Non à cette solution, oui au problème sous-jacent, regardons ensemble les alternatives. » Le client ne veut pas seulement entendre « non » — il veut savoir que vous avez compris ce qu’il lui faut et que vous protégez son investissement de sa propre première intuition. Le « non » seul est arrogant ; le « non + voici la raison + voici ma proposition » est un service.
N'est-ce pas risqué de dire non sur un marché compétitif ?
À court terme cela paraît risqué, à moyen terme c’est l’inverse. Les clients sérieux se souviennent de qui les a sauvés d’une de leurs mauvaises décisions — et reviennent. Les clients qui ne cherchent que des exécutants disant oui à tout sont souvent les pires avec qui travailler, parce que le projet finit mal et qu’ils déchargent la responsabilité. Filtrer avec un non précoce est souvent la façon la plus efficace de gagner les bons clients.
Quelle est la limite au-delà de laquelle le non devient problématique ?
Quand il devient identité plus que service. Un consultant qui dit « non » à tout pour se différencier est aussi inutile qu’un qui dit « oui » à tout. La discipline est de dire oui quand le client a raison, non quand il a tort, et de savoir expliquer la différence dans des termes qu’il puisse évaluer. Ça demande plus de compétence, plus de temps, plus de respect — toutes choses qui manquent quand on industrialise au modèle T&M.