Même modèle, résultats opposés : ce que je délègue à l’IA et ce que je garde

Deux personnes posent la même question à la même IA. Même modèle, même abonnement, même sujet : comment rester visible dans les réponses des assistants conversationnels, maintenant qu’une part croissante des recherches ne débouche plus sur aucun clic.

La première obtient une liste de généralités. Soigner son contenu, travailler son autorité, structurer ses pages. Rien de faux, rien d’actionnable. Elle ressort de l’échange plus inquiète qu’elle n’y est entrée : on lui a expliqué qu’elle avait un problème, sans lui dire quoi faire lundi matin.

La seconde obtient un plan d’action. Des réglages précis, un ordre de priorité, des vérifications à faire, des pages à corriger en premier.

La seconde, c’était moi. Et je ne crois pas une seconde que ce soit parce que je sais mieux poser les questions. La différence tenait à ce que j’avais apporté : les exports de la Search Console, le site lui-même, mes contraintes réelles, mon objectif. Et à ce que j’ai fait ensuite : relancer chaque fois qu’une réponse me paraissait vague, contester chaque fois qu’elle me paraissait fausse. Sans ces données et sans ce contrôle, j’aurais obtenu les mêmes généralités.

Une réponse générique n’est pas neutre. Elle inquiète sans donner de prise. C’est un coût réel, et presque personne ne le nomme.

L’outil est une commodité, son usage ne l’est pas

Presque tout ce qui s’écrit sur l’IA compare des outils : tel modèle contre tel autre, tel abonnement, telle fonctionnalité. C’est la mauvaise comparaison. Deux utilisateurs du même outil obtiennent des résultats radicalement différents, et ce qui les sépare n’est pas dans l’outil.

C’est ce qu’ils ont construit autour : les projets dans lesquels ils travaillent, les données qu’ils y versent, les connecteurs qu’ils ont branchés, les compétences qu’ils ont développées dans leur domaine, et leur capacité à guider une conversation plutôt qu’à la subir.

C’est la même bascule que celle que je décrivais à propos du contenu : le contenu-commodité ne vaut plus rien, la spécificité vécue prend de la valeur. L’IA suit exactement la même règle. Le modèle est disponible pour tout le monde. Ce qu’on en tire dépend de ce qu’on sait déjà.

Je délègue l’exécution, jamais le contrôle

Ce que je confie volontiers à l’IA, ce sont les tâches chronophages. Traiter des jeux de données trop volumineux ou trop complexes pour être lus à la main, et en tirer un audit. Produire un premier jet que je vais réécrire. Maquetter une interface en HTML pour tester une idée avant d’en parler à quiconque. Diagnostiquer un problème technique hors de mon champ. Vérifier des sources.

Mais « chronophage » n’est pas un critère suffisant. Un audit de données est chronophage, et c’est aussi là qu’une erreur coûte le plus cher. Le vrai critère est ailleurs : je délègue l’exécution, jamais le contrôle. Je demande sans cesse des contrôles de cohérence, et je relance dès que quelque chose me surprend.

La surprise est mon meilleur détecteur. Un chiffre trop rond, une réponse trop assurée, un résultat qui contredit ce que je sais : chaque fois, c’est ce léger décalage qui déclenche la vérification. En relisant récemment un de mes anciens articles, j’ai compté treize statistiques attribuées à des sources précises. Trois tenaient. Les dix autres étaient invérifiables, dont plusieurs portaient un millésime postérieur à la date de publication. Je les ai retirées. Une affirmation sans source vaut mieux qu’une source inventée.

Le brief reste à moi

Il y a une chose que je refuse de déléguer : le point de départ. L’idée, l’angle, le brief initial viennent de moi. L’IA intervient ensuite, pour challenger, contester, pointer ce que je n’ai pas vu.

C’est l’inverse de l’usage le plus courant, où l’on demande à la machine de proposer avant de retoucher le résultat. Dans ce sens-là, on obtient ce que le modèle produit par défaut : une moyenne bien écrite. Dans l’autre sens, l’humain pose et la machine conteste — et c’est la contestation qui fait progresser.

J’ai cédé une fois à la facilité. J’ai demandé un visuel à partir de la matière brute, sans aucune ligne directrice. Le résultat m’a plu, et nous avons itéré dessus. Un heureux accident.

Il ne contredit pas la règle, il la précise. J’avais laissé la machine proposer, mais c’est moi qui ai décidé que le résultat valait d’être gardé, et sur quoi itérer. J’avais cédé la génération, pas le jugement. C’est la différence entre la phase divergente et la phase convergente du double diamant : en divergence, sur un sujet sans enjeu, laisser la machine explorer est légitime. En convergence, et dès qu’une décision ou mon nom sont engagés, le brief doit venir de moi.

Une réserve tout de même : si l’accident devient une habitude, on obtient ce que tout le monde obtient. Sans ligne directrice, les modèles convergent vers leur moyenne. C’est pour cela que tant de visuels générés se ressemblent. L’accident est heureux une fois. En série, il fabrique de la commodité.

Comment vérifier ce qu’on ne maîtrise pas

L’IA déduit. Très souvent. Même quand on lui a explicitement demandé de ne pas le faire, elle comble les trous plutôt que d’avouer qu’il lui manque une information. Dans mon domaine, je le vois : je lis des affirmations que je sais fausses, et je corrige.

Hors de mon domaine, c’est une autre affaire. Comment croire sur parole ? C’est impossible. Et c’est là que se trouve le vrai piège : l’IA est la plus utile précisément sur les sujets qu’on ne maîtrise pas. La zone de valeur et la zone de danger se recouvrent.

On pourrait se dire qu’il suffit de juger la logique du raisonnement. Mais hors de son domaine, on n’a justement pas les moyens de l’évaluer. Et les erreurs d’IA ont une particularité redoutable : elles arrivent bien présentées. Un raisonnement faux peut être parfaitement articulé.

Ce que je fais à la place, je m’en suis rendu compte récemment en intervenant sur la base de données de ce site, un terrain qui n’est pas le mien. Je n’ai pas jugé la logique des réponses. J’ai testé les résultats contre la réalité. Un essai à blanc avant chaque remplacement en base. La lecture de la valeur brute avant de la modifier. Un vérificateur de redirection après chaque règle. Un second navigateur en navigation privée pour m’assurer que ce que je voyais n’était pas un cache. Et quand le test contredisait la réponse, c’est le test qui l’emportait. Cela s’est produit plusieurs fois : l’assistant m’a indiqué successivement trois emplacements erronés pour un réglage, et affirmé qu’une licence expirée ne bloquait aucune fonctionnalité, ce qui était faux.

Ça donne une règle en trois cas, que j’applique désormais sans y penser :

• Dans mon domaine, je vérifie par la connaissance : je repère ce que je sais faux.
• Hors de mon domaine, je vérifie par le test : le résultat doit être observable, et je l’observe avant de m’y fier.
• Ni connaissable ni testable, je ne délègue pas. Ou je traite la réponse comme une hypothèse, jamais comme un fait.

Être certain que le résultat sera juste à 100 % ? Impossible. Mais ce n’est pas davantage possible avec un collaborateur humain, et on ne l’exige pas. On exige des processus qui détectent les erreurs avant qu’elles coûtent. La bonne question n’est pas le taux d’erreur de l’IA. C’est la capacité à détecter l’erreur à temps.

Un référentiel qui apprend de ses erreurs

Travailler avec une IA ressemble plus qu’on ne le croit à travailler avec une équipe : on apprend de ses erreurs, ensemble, et on évite de les refaire.

Un exemple concret. L’assistant me proposait des méta descriptions plus longues que ce que préconisait mon outil de référencement. Nous avons testé, itéré, constaté l’écart. Puis nous avons écrit la règle, une fois, dans un référentiel unique et privé. Elle ne se discute plus à chaque article.

Ce référentiel sert trois choses. Ne pas se répéter : je n’ai pas à réexpliquer le contexte à chaque conversation. Ne pas s’appuyer sur des données périmées : un diagnostic daté est remplacé, pas empilé. Et surtout, capitaliser sur ce qui a mal tourné : les erreurs commises une fois, les arbitrages retenus, les choix contre-intuitifs qui ne figurent dans aucune documentation.

C’est ce qui explique en grande partie l’écart du début. Le modèle est le même pour tout le monde. La mémoire des erreurs, elle, n’appartient qu’à celui qui l’a construite.

Pour une équipe produit, la conséquence est directe : une doctrine encodée cesse d’être une habitude individuelle pour devenir un actif partagé, versionné, qui survit aux départs et aux changements d’outils. C’est un sujet d’organisation autant qu’un sujet d’outillage.

En entreprise, la question n’est plus « faut-il »

Tout ce qui précède vient de mes projets personnels, où je suis libre de mes outils et de mes données. En entreprise, et a fortiori dans les secteurs réglementés, la question ne se pose plus dans les mêmes termes. Il ne s’agit plus de savoir s’il faut utiliser l’IA, mais dans quel cadre : un environnement sécurisé, des outils validés, des règles d’usage claires, et des données qui ne sortent pas.

Le principe, lui, reste transposable. Déléguer l’exécution, garder le contrôle. Poser le brief avant de demander une contestation. Vérifier par la connaissance ce qu’on maîtrise, par le test ce qu’on ne maîtrise pas. Et écrire ce qu’on apprend, pour ne pas avoir à le réapprendre.

Ce qui vient ensuite

Il reste une question que je n’ai pas traitée ici, et qui me paraît la plus importante pour une organisation produit : quand un Product Manager peut maquetter seul, en deux heures, un prototype qui aurait mobilisé une équipe pendant une semaine, qu’est-ce que ça change au dimensionnement des équipes et au rôle de chacun ? Ce sera le prochain article.

En attendant, sur la manière dont je conduis une équipe produit au quotidien — rituels, arbitrages, relation aux parties prenantes —, j’ai détaillé ma pratique dans piloter une équipe produit.