La semaine dernière, j’ai demandé à Claude de m’écrire une proposition technique pour un client.
Il a produit un document impeccable en quarante secondes. Architecture propre, estimation des coûts sur trois environnements, timeline avec milestones, analyse des risques. Mise en forme parfaite. Langage professionnel.
J’ai tout jeté.
Pas parce que c’était faux. C’était techniquement correct, probablement meilleur que ce que j’aurais écrit d’un jet. Je l’ai jeté parce que ce client, trois mois plus tôt, nous avait dit en visio que son CTO avait été remercié après un projet raté avec une approche similaire à celle proposée.
On ne le trouve dans aucun dataset. Ce n’est dans aucun prompt. C’est une cicatrice organisationnelle qui vit dans la mémoire de ceux qui étaient à cette visio, et qui change tout : le ton de la proposition, le choix de la solution, jusqu’aux mots à utiliser et à ceux à éviter.
L’IA avait produit la bonne réponse à la mauvaise question. C’est une chose qu’elle fait très bien.
Le travail invisible
Je dirige une société volontairement de petite taille. Mon travail, sur le papier, c’est de prendre des décisions : quel produit construire, pour qui, avec quelles priorités, pour quand. Si je regardais ma fiche de poste, un modèle de langage pourrait faire quatre-vingt-dix pour cent de ce que je fais. Peut-être plus.
Mais la fiche de poste est un mensonge. Comme toutes les fiches de poste.
Mon vrai travail est fait de choses qui ne sont dans aucun backlog ni dans aucun document de projet. Il est fait de silences pendant les réunions, de ce moment où un client dit « oui, c’est bon » avec un ton qui veut dire « non, ça ne va pas du tout, mais je n’ai pas envie d’en discuter maintenant ».
Il est fait de déjeuners avec un collègue qui ne livre plus depuis deux semaines et qui, au deuxième café, te dit qu’il traverse un moment difficile à la maison.
Il est fait de la décision, prise à 23 h, de ne pas répondre à un mail provocateur d’un stakeholder et d’attendre le lendemain matin, quand les mots pèsent moins.
Rien de tout ça n’est calculable. Et je ne crois pas que ce soit juste un problème de contexte manquant qu’on résout avec un prompt plus long ou un RAG plus sophistiqué.
C’est un type de connaissance différent. Située, relationnelle, presque corporelle.
Vous savez qu’une réunion va mal parce que vous sentez la tension dans la pièce. Vous savez qu’une estimation est gonflée parce que vous connaissez celui qui l’a faite. Vous savez qu’une exigence doit être refusée non pour des raisons techniques, mais parce que l’accepter déplacera le produit dans une direction d’où l’on ne revient pas. Et vous le savez parce que vous y êtes déjà allé trois projets plus tôt, avec un autre client, et que vous avez les cicatrices pour le prouver.
L’IA travaille sur ce qui est explicite. Mon métier vit dans ce qui est implicite.
Quatre choses que je n’arrive pas à déléguer
J’ai fait un exercice, un peu par curiosité, un peu par peur : identifier les parties de mon travail qu’un modèle de langage, aussi avancé soit-il, n’arrive pas à faire.
Pas les parties qu’il ne fait pas encore. Celles que, par sa nature, il ne peut probablement pas faire. Ou en tout cas pas de la même manière.
J’en ai trouvé quatre.
La première, c’est lire les gens
Je ne parle pas de distribuer des tâches ou de faire des performance reviews. Ça, un fichier Excel le fait, et souvent mieux.
Je parle de la vraie partie. Comprendre qu’un collègue qui produit soudain du travail bâclé n’a pas un problème de compétence, mais un problème de motivation. Et que ce problème de motivation vient du fait que sur les trois derniers sprints, vous l’avez mis sur des activités qu’il considérait sous son niveau.
Et qu’il ne vous l’a pas dit parce qu’il a peur de paraître arrogant.
Et que vous le savez parce que vous le connaissez depuis quatre ans et que vous savez comment il réagit quand il se sent sous-évalué.
Cette chaîne causale n’est écrite nulle part. La moitié des maillons n’a jamais été verbalisée. Elle existe dans l’espace entre deux personnes qui travaillent ensemble assez longtemps pour se comprendre sans parler.
Manager une équipe, ce n’est pas optimiser des ressources. C’est naviguer les complexités émotionnelles d’un groupe d’êtres humains qui passent ensemble plus de temps qu’avec leurs familles.
Et le faire sans manuels, sans métriques, souvent sans même s’en rendre compte.
La deuxième, c’est comprendre ce qu’un client veut vraiment
Pas ce qu’il dit vouloir. Ce qu’il veut vraiment. Deux choses presque toujours différentes.
Un client qui vous demande une GED ne veut souvent pas une GED. Il veut que son chef arrête de lui demander où sont les fichiers.
Un client qui vous demande une app mobile veut prouver au board que sa division innove.
Un client de l’administration publique qui met en appel d’offres une plateforme numérique a souvent besoin de quelque chose de bien plus simple, mais l’appel d’offres a été écrit en copiant celui d’une autre commune aux besoins complètement différents.
Mon travail, c’est de creuser sous la demande jusqu’à trouver le besoin. Et le besoin est presque toujours politique, organisationnel, émotionnel. Rarement technique.
On y arrive en posant des questions qui n’ont rien à voir avec la technologie. Qui utilisera ce système ? Qui a décidé qu’il fallait le faire ? Que se passe-t-il si on ne le fait pas ? Qui y gagne et qui y perd ?
Ce sont des questions qu’une IA ne sait pas poser parce qu’elle ne sait pas si et quand il faut les poser.
C’est peut-être la partie qui m’inquiète le plus. Ce n’est pas que la machine réponde mal. C’est qu’elle réponde bien à une question que personne n’aurait peut-être dû poser ainsi.
La troisième, c’est donner du poids au contexte qui n’est écrit nulle part
Chaque produit a une histoire. Pas celle écrite dans la doc, qui est la version officielle. La vraie histoire est faite de compromis acceptés parce que le budget était fini, de features ajoutées pour contenter un stakeholder qui a depuis changé de poste, de choix qui étaient faux mais qui sont désormais si entrelacés avec les processus du client que les enlever coûterait plus cher que de vivre avec.
Quand je dois décider si la prochaine release doit réécrire un module ou ajouter une fonctionnalité, je ne peux pas demander à un modèle.
Parce que la bonne réponse dépend de qui utilise ce module, comment, de ce qui se passait dans le projet quand il a été construit, de la relation actuelle avec le client, et si ce client aura encore le budget pour la phase deux dans trois mois.
Une IA peut vous dire quelle est la roadmap idéale dans l’absolu.
Un product leader sait quelle est la roadmap juste pour ce produit, avec cette équipe, pour ce client, à ce moment.
La différence entre les deux, c’est la différence entre un livre de recettes et un cuisinier.
La quatrième, c’est dire non
C’est la plus importante et la moins technique de toutes.
Dire non à une feature qui semble raisonnable mais qui amènera le produit dans une impasse.
Dire non à un client qui veut une timeline impossible, en sachant que vous perdrez l’appel d’offres.
Dire non à un stakeholder qui pousse pour un pivot séduisant mais qui détruirait la valeur construite en deux ans.
Dire non à vous-même quand l’enthousiasme pour une nouvelle idée vous fait perdre de vue que vos utilisateurs ont besoin de quelque chose qui marche, pas de quelque chose d’innovant.
Le non est un acte de jugement qui demande courage, contexte et responsabilité.
L’IA ne dit jamais non. Elle ne peut pas se le permettre. Son design est optimisé pour être utile, pour donner des réponses, pour résoudre.
Mais parfois la chose la plus utile est de s’arrêter. Parfois la meilleure réponse est « on ne le fait pas ».
Et aucun prompt au monde ne peut apprendre à un modèle quand ce moment est arrivé, parce que le reconnaître exige quelque chose qu’aucun training set ne contient : le poids des conséquences sur ses propres épaules.
Le paradoxe de l’amplification
Que ce soit clair, je ne dis pas que l’IA est inutile. Ce serait malhonnête, et bête. Je l’utilise tous les jours. Mon équipe l’utilise pour produire, documenter, analyser. On gagne des heures, des jours, des semaines, des mois. La qualité des livrables a monté. Je ne reviendrais pas en arrière.
Mais il y a un paradoxe que je vois émerger et qui m’inquiète.
Plus l’IA s’occupe des parties « productibles » du métier — documents, analyses, specs, code — plus la valeur se concentre dans les parties « impondérables » : les décisions, les relations, les non.
Et ce sont précisément les parties qui ne s’apprennent pas en lisant de la doc ou en suivant des cours. Elles s’apprennent en se trompant, en observant, en restant dans une pièce avec d’autres personnes pendant des années.
Le risque, je me le demande, c’est qu’une génération de professionnels grandisse en déléguant les parties exécutables sans jamais traverser la phase où ces parties vous apprennent le métier.
Écrire une proposition fausse, gérer une démo qui s’effondre devant le client, perdre un contrat parce que vous avez sous-estimé une exigence, ce n’est pas seulement de la souffrance formative. C’est le processus par lequel vous développez l’intuition qui vous permettra ensuite de prendre les décisions que l’IA ne peut pas prendre.
Si vous sautez cette étape, vous arrivez à la table des négociations sans jamais avoir senti le poids d’un mauvais choix. Et à cette table, l’IA ne peut pas vous aider.
Le métier qui reste
Mon métier change. Il ne disparaît pas, il change de forme.
Le temps que je passais à produire des livrables, je le passe à réfléchir à ce que ces livrables devraient dire.
Le temps que je passais à chercher de l’information, je le passe à décider quoi en faire.
Le temps que je passais sur les parties répétitives, je le passe à parler aux gens, collègues, clients, utilisateurs.
C’est un déplacement vers le haut dans la chaîne de valeur, et à certains égards c’est une libération.
Mais cela apporte une responsabilité nouvelle, qui est peut-être aussi une responsabilité ancienne vue avec d’autres yeux : ne pas confondre vitesse et compétence.
Le fait qu’un outil m’aide à produire plus ne signifie pas que je sais plus. Cela signifie que j’ai plus de temps pour appliquer ce que je sais, ou pour découvrir ce que je ne sais pas, si je suis honnête avec moi-même.
L’IA sait ce qui a été écrit.
Mon métier, c’est de savoir ce qui n’a pas été écrit, et souvent ce qui ne peut pas être écrit.
Tant que ça restera ainsi, et je soupçonne que ça le restera longtemps, le métier reste. Il change de forme, de rythme, d’outils.
Mais il reste.
Ce que l’IA ne sait pas de mon métier, c’est, au fond, ce qui en fait un métier et non un algorithme.
Ce qu'il faut retenir
La connaissance tacite (relations, appels, commentaires en marge) est ce qui ne laisse pas de trace écrite — donc pas digestible par un LLM.
Un consultant expérimenté tient ensemble projet demandé, problème réel, politique interne du client, histoire de la relation : synthèse stratégique non automatisable.
L’IA accélère la rédaction formelle, pas la décision sur ce qu’il faut écrire et ce qu’il faut taire.
Industrialiser le conseil comme une pipeline produit des livrables techniquement corrects et politiquement aveugles — le client paie deux fois.
Questions & réponses
Qu'est-ce que la « connaissance tacite » que l'IA ne peut pas répliquer ?
La connaissance qui n’est écrite nulle part parce qu’elle vient d’années de relations, d’erreurs, de conversations spécifiques. Écrire une proposition pour un client demande de savoir que le décideur réel n’est pas le signataire mais l’IT manager dans l’ombre, que la fois précédente il s’est offusqué d’une phrase précise, que l’entreprise traverse un moment délicat qui n’est pas dans le brief. Aucun LLM n’y a accès — et sans ça, la proposition « parfaite » est fausse là où ça compte.
Mais un modèle qui lit tout l'historique des contacts ne peut-il pas le saisir ?
En théorie oui. En pratique non — parce que la connaissance tacite n’est pas dans les documents, elle est dans la mémoire des personnes. L’appel à 19 h, le commentaire en marge en réunion, le « mais ne l’écris pas par mail » — ces informations ne laissent pas de trace écrite précisément parce qu’elles sont importantes. Confier à un LLM ce qui a été écrit, c’est travailler avec un petit pourcentage de ce qui compte.
Que fait un consultant expérimenté qu'un modèle d'IA ne peut pas faire ?
Tenir simultanément en tête : le projet formellement demandé, le problème réel du client, la politique interne du client, l’histoire de la relation, ses propres capacités de livraison, les contraintes économiques, la soutenabilité dans le temps. Et synthétiser le tout en une proposition qui fonctionne sur tous les niveaux, pas seulement le technique. L’IA peut aider sur la rédaction formelle — la synthèse stratégique reste humaine.
Cette connaissance tacite peut-elle être explicitée ?
En partie seulement. Toute tentative de la coder dans des documents ou un CRM en capture la surface mais en perd la nuance. C’est pourquoi le conseil sérieux reste un métier de personnes qui parlent à des personnes, malgré les outils. Et pourquoi les « consultants » industrialisés à grande échelle livrent des projets techniquement corrects et politiquement aveugles.
L'auteur
