← Tous les articles
    23 juin 2026 · cadrage · conseil · arbitrage

    Savoir dire non à un cas d'usage IA

    La compétence la plus utile d'un consultant IA, et la plus mal payée sur le moment.

    Par Marie Van Haecke

    Il y a une phrase que je prononce plusieurs fois par an, souvent en fin de premier atelier : « je ne pense pas qu'il faille faire ça ». Elle coûte de la mission sur le moment. Elle rapporte à peu près tout le reste ensuite. Parce qu'un client qui t'a entendu refuser une fois te croit quand tu dis oui.

    Les quatre signaux qui font que je refuse

    Je ne refuse pas sur une intuition. Je refuse quand un de ces quatre éléments manque, et qu'aucun plan crédible ne permet de le récupérer dans le délai du projet.

    Il n'y a pas de donnée

    Pas « la donnée est sale » — ça se traite. Pas de donnée du tout. L'historique n'existe pas, il est dans des messageries personnelles, ou dans la tête de trois personnes qui ne l'ont jamais écrit.

    Le test est simple : demande à voir cinquante exemples réels. Pas une description du gisement, cinquante fichiers ou lignes que tu peux ouvrir. Si personne ne peut les produire en deux semaines, le projet ne démarre pas, il attend.

    On ne saura pas dire si ça marche

    Je pose toujours la question : à quoi ressemble une bonne réponse, et qui en juge ? Quand personne ne sait répondre, ou quand deux personnes du même service donnent deux réponses contradictoires, on n'a pas de critère de succès. Sans critère, un projet IA ne se termine jamais — il se traîne jusqu'à ce que le budget s'épuise.

    Il n'y a pas de propriétaire

    Un nom, un vrai, quelqu'un dont le travail sera jugé sur cet outil dans un an. Pas un comité. Pas « la DSI ». Pas un sponsor qui donne son accord mais ne suivra rien.

    C'est le signal que je regarde en dernier et qui prédit le mieux. Un cas d'usage moyen avec un propriétaire engagé passe en production. Un cas d'usage brillant sans propriétaire meurt à la première réorganisation.

    La demande vient de la peur

    « Nos concurrents s'y mettent. » « Le conseil d'administration a demandé où on en est. » « On ne peut pas ne rien faire. »

    Ce ne sont pas des besoins, ce sont des angoisses. Elles sont légitimes, et elles méritent une réponse — mais la réponse est rarement le projet qu'on me demande de lancer. Un projet motivé par la peur se reconnaît à un détail : personne ne sait décrire l'utilisateur. On parle de l'entreprise, du marché, du retard. Jamais de la personne devant l'écran.

    Le cas difficile : le projet déjà annoncé

    C'est la vraie situation compliquée. Le dirigeant a présenté le chantier en comité de direction, ou pire, en séminaire devant toute l'équipe. Il n'a pas besoin d'un avis, il a besoin d'une sortie.

    Ce que j'ai appris à faire, dans l'ordre.

    Ne jamais contester en séance publique. Le désaccord se dit en tête-à-tête. En réunion élargie, un « non » frontal oblige la personne à défendre sa position, et elle la défendra.

    Séparer l'intention du dispositif. L'intention est presque toujours bonne. Ce qui ne tient pas, c'est la forme choisie. Je le formule à peu près comme ça :

    « L'objectif est le bon. La manière dont on l'a formulé nous emmène droit dans le mur pour trois raisons précises. Voici une autre façon de tenir la promesse que tu as faite. »

    Toujours arriver avec une alternative. Un refus sans proposition, c'est un consultant qui se protège. Ce que j'apporte à la place : un chantier plus petit et réellement finançable, un travail préalable sur la donnée présenté comme une étape du projet annoncé, ou un cas d'usage voisin qui coche les quatre cases. Le dirigeant peut alors dire « on a affiné le périmètre » — ce qui est vrai, et ce qui ne le met pas en défaut.

    Écrire le refus. Deux paragraphes dans le compte rendu : ce qui manque, ce qu'il faudrait pour rouvrir le sujet, à quelle échéance on regarde à nouveau. Six mois plus tard, cette trace protège tout le monde, y compris ceux qui étaient contre toi ce jour-là.

    Ce que ça change dans la relation

    J'ai accompagné une cinquantaine d'entrepreneurs et de dirigeants entre Grabloop et Entrepreneurs.com. Le schéma se répète : les missions les plus longues, et les recommandations qui suivent, viennent presque toutes de gens à qui j'ai dit non au moins une fois.

    La raison est simple. Un prestataire qui dit oui à tout devient une variable d'ajustement — on lui demande son avis pour la forme, pas pour la décision. Quelqu'un qui refuse parfois devient un interlocuteur dont l'accord a une valeur. Ce n'est pas une posture, c'est de l'économie de la confiance.

    Il y a une contrepartie honnête : ça coûte. Des missions ne se signent pas. Des clients partent chercher ailleurs quelqu'un qui dira oui, et le trouvent. Certains reviennent un an plus tard avec le projet en panne et le budget consommé. C'est un métier où on encaisse le coût tout de suite et le bénéfice plus tard.

    Ce qu'il ne faut pas faire

    Dire non par confort intellectuel. Il y a des cas d'usage inconfortables, mal cadrés au départ, qui méritent qu'on les travaille au lieu de les écarter. Le refus doit s'appuyer sur un manque concret et vérifiable, pas sur une préférence de méthode.

    Dire non sans avoir vu le terrain. Deux entretiens avec les personnes qui font le travail suffisent souvent à retourner un avis, dans un sens comme dans l'autre.

    Le réflexe à garder

    Avant ta prochaine réponse à une demande de cas d'usage IA, pose les quatre questions : où est la donnée, qui juge du résultat, qui en est propriétaire, et d'où vient vraiment la demande. Si deux réponses manquent, ne cherche pas à sauver le projet. Cherche ce qu'il faudrait pour qu'il devienne finançable, et propose ça.

    À lire aussi

    Vous travaillez sur un sujet proche ?

    J'accompagne les organisations sur l'audit IA, le cadrage de produits IA, les agents et l'automatisation. Si cet article recoupe une question que vous vous posez, on peut en parler.