Travailler efficacement avec l’IA

La première partie de cette série soutenait que les travaux importants assistés par l’IA peuvent bénéficier d’une redondance indépendante. La deuxième soutenait que l’utilisateur doit choisir le bon type d’IA avant de juger ce que l’IA peut faire.

Supposons maintenant que ces deux conditions soient remplies.

Vous avez sélectionné un modèle capable. Vous avez prévu une voie de vérification indépendante pour les travaux importants. Le résultat reste médiocre.

À ce stade, une question plus difficile mérite d’être posée :

Et si le problème n’était pas l’IA ? Et s’il venait de l’utilisateur ?

Ce n’est pas une attaque contre l’utilisateur. C’est une question de système. Si l’humain définit l’objectif, fournit le contexte, choisit la séquence de travail, approuve les résultats intermédiaires et décide de ce qui est terminé, alors l’humain n’est pas extérieur au flux de travail de l’IA. Il en est l’un des composants.

L’utilisateur fait partie du système

Nous parlons souvent de la performance de l’IA comme si le modèle fonctionnait de manière isolée. Dans le travail réel, c’est rarement le cas.

L’utilisateur décide quel est le problème. Il décide quelles informations fournir. Il décide de ce qui ne doit pas changer. Il décide si le premier résultat est acceptable, si une correction est nécessaire et si le travail doit continuer.

Chacune de ces décisions peut améliorer le résultat. Chacune peut aussi le dégrader.

Le modèle peut échouer. Le logiciel peut échouer. Les données peuvent échouer. Les hypothèses peuvent échouer. Et l’utilisateur peut échouer lui aussi.

Le reconnaître n’est pas anti-humain. C’est du contrôle qualité élémentaire.

Un meilleur modèle ne peut pas sauver un mauvais processus

Il existe une tendance à traiter l’IA comme un distributeur automatique : insérer un prompt, recevoir un produit fini, puis blâmer la machine si le résultat est mauvais.

Cette approche peut fonctionner pour une demande simple. Elle devient fragile lorsque la tâche comporte des dizaines d’exigences, de dépendances, d’exceptions, de fichiers, de langues, de contraintes techniques et de critères d’acceptation.

Un modèle plus puissant peut tolérer un mauvais processus plus longtemps. Il peut mieux deviner ce que l’utilisateur voulait dire. Il peut se remettre plus facilement d’une ambiguïté. Mais aucun modèle ne devrait être censé compenser indéfiniment un objectif qui n’a jamais été clairement défini.

Un meilleur outil peut augmenter les capacités. Il ne supprime pas la nécessité de gérer le travail.

Le « prompt engineering » n’est pas magique

L’expression « prompt engineering » peut donner l’impression qu’il existe quelque part une phrase parfaite capable de débloquer un résultat parfait.

Pour un travail complexe, ce modèle mental est généralement mauvais.

Un bon prompt compte. Un langage clair compte. De bons exemples comptent. Mais la compétence la plus large consiste à gérer l’interaction dans le temps.

Quel est l’objectif ? Quel contexte compte ? Quelles contraintes sont absolues ? Quelles préférences sont facultatives ? Que faut-il faire d’abord ? Que faut-il vérifier avant l’étape suivante ? Quelle preuve démontrerait que la tâche est terminée ?

Une instruction courte au bon moment dans un flux de travail discipliné peut être plus efficace qu’un paragraphe sophistiqué contenant vingt exigences.

Définir l’objectif avant l’instruction

Les utilisateurs savent souvent ce qu’ils veulent lorsqu’ils le voient, sans avoir défini ce que signifie réellement la réussite.

Cette distinction compte.

« Améliore ce site » n’est pas un critère d’acceptation. « Modifie uniquement les trois images indiquées et laisse tous les autres fichiers inchangés » s’en rapproche beaucoup plus. « Améliore la traduction » est vague. « Préserve le sens, la terminologie technique, le ton, les noms et la hiérarchie tout en produisant un français et un arabe naturels et professionnels » donne des limites au travail.

L’objectif doit identifier à la fois ce qui doit changer et ce qui doit rester protégé.

En termes d’ingénierie, l’IA a besoin d’un état cible et de contraintes.

Décomposer le travail avant que le travail ne se décompose

L’un des moyens les plus simples d’améliorer un travail assisté par IA consiste à cesser de tout demander en une seule fois.

Un travail complexe doit souvent être divisé en étapes contrôlées : établir la base, définir une catégorie de changement, l’exécuter, l’inspecter, vérifier que les éléments non concernés sont restés intacts, puis continuer.

Ce n’est pas une règle spéciale inventée pour l’IA. C’est une discipline classique de dépannage.

Si dix changements sans rapport sont effectués en une seule étape et que le système casse, il devient difficile d’en localiser la cause. Si un changement contrôlé est effectué puis vérifié, la surface de défaillance est plus petite.

L’IA rend cette discipline encore plus utile parce que le système interprète les instructions. Chaque exigence supplémentaire augmente la possibilité qu’un malentendu se propage dans le reste du travail.

Préserver une base connue comme correcte

Avant de modifier un système qui fonctionne, sachez ce que « fonctionner » signifie et conservez une version qui le prouve.

Une base connue comme correcte fournit plus qu’une sauvegarde. Elle fournit une preuve.

Lorsque le nouveau résultat est mauvais, l’utilisateur peut le comparer au dernier état approuvé au lieu d’essayer de reconstruire de mémoire ce qui aurait dû rester inchangé.

C’est particulièrement important dans les déploiements assistés par IA, où une page visible peut sembler correcte alors que des composants partagés, des routes, des styles, des ressources ou la configuration ont changé ailleurs.

La base transforme « je pense que quelque chose a changé » en « ce fichier a changé alors que ce n’était pas autorisé ».

Vérifier chaque étape avant de continuer

Un schéma d’échec fréquent consiste à accepter un résultat intermédiaire parce qu’il semble suffisamment proche, puis à construire cinq étapes supplémentaires au-dessus.

Lorsque l’erreur d’origine est enfin découverte, le travail ultérieur en dépend déjà.

La vérification doit donc intervenir tant que la correction reste peu coûteuse.

Si l’IA modifie un fichier, inspectez le fichier. Si elle change une route, testez la route. Si elle traduit une page, comparez le sens et la structure. Si elle génère du code, exécutez les contrôles pertinents. Si elle affirme qu’une seule zone a changé, comparez l’artefact livré à la base approuvée.

Ne laissez pas une explication persuasive remplacer une preuve.

Cesser de construire sur un mauvais résultat

Une autre erreur fréquente consiste à continuer de réparer une conversation qui aurait dû être abandonnée plusieurs instructions auparavant.

Le premier résultat contient une erreur. Une correction est ajoutée. La correction introduit un autre problème. Une nouvelle instruction est ajoutée. Puis une exception. Puis une clarification. Puis une instruction expliquant quelle instruction précédente ne s’applique plus.

À la fin, la conversation devient une pile de correctifs au lieu d’une description propre du résultat recherché.

À ce stade, continuer peut être pire que recommencer.

Revenez au dernier état connu comme correct. Reformulez l’objectif actuel. Supprimez les corrections et hypothèses devenues obsolètes. Recommencez depuis une base propre.

Les ingénieurs annulent un code cassé. Les techniciens ramènent les équipements à des configurations connues comme correctes. Les flux de travail avec l’IA méritent la même discipline.

Recommencer n’est pas un échec. C’est parfois une récupération contrôlée.

Examiner l’artefact, pas l’explication

Une IA peut affirmer sincèrement qu’elle n’a modifié que ce qui était demandé tout en se trompant.

L’explication est générée par le même système qui a effectué le travail. Elle ne constitue pas une preuve indépendante du travail.

Pour le logiciel, inspectez les fichiers, les routes, la configuration, les tests et les différences. Pour la recherche, inspectez les preuves. Pour les calculs, refaites les valeurs critiques. Pour les documents, vérifiez les faits, la structure et les sources. Pour les traductions, comparez le sens et pas seulement la fluidité.

Plus l’examen se rapproche de l’artefact réel, plus il devient utile.

Si vous ne pouvez pas reconnaître une mauvaise réponse, vous ne supervisez pas

L’IA peut produire très rapidement un résultat soigné. Cette qualité de surface crée l’un des principaux pièges du travail assisté par IA.

Un code incorrect peut sembler professionnel. Une analyse faible peut paraître autoritaire. Une fausse hypothèse peut être présentée avec assurance. Une traduction fluide peut néanmoins modifier le sens.

L’utilisateur doit donc comprendre suffisamment l’objectif pour reconnaître un résultat inacceptable.

Cela ne signifie pas que l’utilisateur doit maîtriser chaque détail mieux que l’IA. Cela signifie qu’il doit savoir quelles preuves exiger, quelles contraintes comptent, quand une expertise spécialisée est nécessaire et quelles décisions ne peuvent pas simplement être redéléguées au modèle.

Si l’utilisateur ne dispose d’aucun moyen de distinguer une réponse correcte d’une réponse fausse mais convaincante, le système n’est plus supervisé. Il est simplement cru.

Ce n’est pas la même chose.

Un meilleur retour produit de meilleures corrections

« Faux » est un retour, mais c’est un retour faible.

Une correction utile identifie le défaut, indique l’état attendu et limite la portée de la réparation.

Au lieu de « répare le site », une meilleure instruction peut identifier la page exacte, l’élément exact, la base approuvée et la règle selon laquelle rien d’autre ne doit changer.

Au lieu de réécrire plusieurs fois un document entier parce qu’un paragraphe est faible, isolez le paragraphe et expliquez ce qui manque.

L’objectif n’est pas de parler à l’IA dans un langage spécial. L’objectif est de réduire l’ambiguïté.

La même IA peut paraître brillante ou médiocre selon son utilisateur

Imaginez deux personnes utilisant exactement le même modèle.

La première donne une instruction vague, accepte la première réponse, continue d’ajouter des corrections sans vérifier les étapes intermédiaires et construit sur un résultat de plus en plus instable. Le projet finit par échouer. La conclusion : l’IA est inutile.

La seconde définit l’objectif, fournit le contexte pertinent, précise ce qui ne doit pas changer, divise le travail en étapes, vérifie chaque étape, compare les résultats importants aux preuves et recommence lorsque l’interaction devient confuse.

Le même modèle peut alors paraître beaucoup plus performant.

La différence ne vient peut-être pas de l’intelligence du modèle. Elle peut venir de la qualité du flux de travail.

C’est pourquoi l’évaluation de l’IA ne devrait pas séparer l’outil de la manière dont il est utilisé.

Le jugement humain est la dernière couche de redondance

La première partie introduisait une deuxième IA comme couche de vérification indépendante. La deuxième ajoutait le choix délibéré de l’outil. Mais aucune des deux ne supprime le besoin d’une autorité d’acceptation finale.

Une IA peut examiner une autre IA. Des tests automatisés peuvent vérifier certains résultats. Des modèles peuvent se contredire. Des spécialistes peuvent inspecter les zones à risque élevé.

Mais à un moment donné, un humain doit encore décider si le résultat livré sert réellement l’objectif et si les preuves disponibles sont suffisantes pour l’accepter.

Cette décision humaine constitue la dernière couche de redondance.

Travailler efficacement avec l’IA, c’est assumer la responsabilité de l’interaction

Parfois, le problème vient réellement du modèle.

Les modèles comprennent mal certaines instructions. Ils produisent des affirmations non étayées. Ils modifient des éléments qu’on leur avait demandé de préserver. Ils peuvent présenter avec assurance des résultats incorrects. Ces échecs sont réels et il ne faut pas les nier.

Mais une utilisation sérieuse de l’IA impose une deuxième question lorsque quelque chose se passe mal : qu’aurais-je pu faire différemment ?

L’objectif était-il clair ? Le bon contexte a-t-il été fourni ? La tâche était-elle trop large ? Ai-je vérifié l’étape précédente ? Ai-je continué à corriger une conversation cassée au lieu de recommencer ? Ai-je accepté une réponse parce qu’elle semblait convaincante ? Ai-je délégué une décision qui exigeait mon propre jugement ?

Parfois, la réponse restera : le modèle a échoué.

Parfois, non.

Apprendre à faire la différence fait partie du travail efficace avec l’IA.

L’avantage n’appartiendra pas seulement à la personne qui a accès au modèle le plus puissant. Il appartiendra aussi à celle qui sait définir le travail, le superviser, le vérifier et assumer la responsabilité de la qualité de l’interaction.

Parce que parfois, le problème vient réellement de l’IA.

Et parfois, le problème pourrait venir de l’utilisateur.