Comment tester une tâche avec l'IA dans une PME : protocole A/B/C

Le Lab #1 a testé vingt tâches sur cinq assistants et trois modes d'usage. Ce guide fait l'inverse : il réduit ce protocole à ce qu'une PME peut exécuter sur une seule tâche, en une demi-journée, sans outil supplémentaire. La méthode est celle du Lab, aucune autre n'est introduite ici.

Un avertissement avant de commencer : ce guide vous donne une méthode, pas un résultat. Les chiffres cités par ailleurs dans nos analyses proviennent d'une campagne simulée. Le seul résultat qui vaudra pour votre entreprise est celui que vous produirez avec ce protocole.

Étape 1 — Choisir la tâche

Une seule tâche, et la bonne. Quatre critères de sélection, tous nécessaires.

—Elle est récurrente : au moins une fois par semaine. Une tâche rare ne rentabilise jamais le dispositif de contrôle.

—Son livrable est identifiable : un document, un message, un tableau, une synthèse. Pas « aider à réfléchir ».

—On sait dire ce qu'est un bon résultat. Si personne ne sait l'écrire, c'est le vrai problème à traiter d'abord.

—Son échec est réparable. Ne commencez pas par ce qui engage un client, un contrat ou une paie.

Écrivez la tâche en une phrase, avec son livrable attendu. Cette phrase servira de base à toutes les demandes du test.

Étape 2 — Établir la référence humaine

Sans référence, il n'y a pas de comparaison possible : c'est la règle la plus souvent violée dans les tests d'IA en entreprise. Faites exécuter la tâche une fois, complètement, par la personne qui la fait habituellement, avec un chronomètre. Notez trois choses : le temps total en minutes, la qualité du résultat sur une échelle de 1 à 5 selon vos propres critères, et les points de vigilance rencontrés.

Cette référence est un temps de référence, pas un standard : une seule exécution ne dit rien de la variabilité humaine. Elle suffit néanmoins à donner un ordre de grandeur.

Étape 3 — Exécuter le test A/B/C

Trois exécutions de la même tâche, avec le même assistant, sur le même jour. Ne changez qu'une chose entre les trois : la manière de demander.

—Mode A — usage spontané. On pose la demande telle qu'on la formulerait naturellement, on prend la première sortie.

—Mode B — contexte structuré. On fournit le contexte, les contraintes, le format attendu et les critères de réussite écrits, en une seule demande.

—Mode C — interaction. On part du mode B, puis on corrige, on précise, on fait reformuler jusqu'à obtenir un livrable acceptable.

Pour chaque mode, chronométrez quatre phases séparément : préparation, relecture, correction, finalisation. Le temps de production de l'assistant se note à part : ce n'est pas du temps humain.

Étape 4 — Comparer les modes

Quatre mesures par mode, notées dans un tableau à quatre colonnes.

—Qualité, de 1 à 5, contre vos critères écrits à l'étape 1.

—Supervision nécessaire, de 1 à 5 : combien de contrôle humain le résultat exige. Un score élevé est défavorable.

—Risque, de 1 à 5 : la gravité de ce qui se passe si une erreur passe. Un score élevé est défavorable.

—Temps humain total, en minutes, et gain net par rapport à la référence de l'étape 2.

Comparez d'abord A et B. C'est l'écart le plus informatif, et le moins coûteux à exploiter : il ne dépend que de votre manière de demander.

Étape 5 — Contrôler le résultat

Deux contrôles, tirés du protocole du Lab, qui distinguent un test sérieux d'une impression.

—Le rejeu : relancez le meilleur mode une seconde fois, à l'identique. Si la qualité s'écarte d'un point ou plus, l'outil n'est pas stable sur cette tâche, et votre première mesure était de la chance.

—La double évaluation : faites noter le même livrable par une deuxième personne, sans lui montrer la première note. Si les deux verdicts diffèrent, ce sont vos critères de qualité qui doivent être précisés — pas l'outil qui doit changer.

Ajoutez, si la tâche s'y prête, une anomalie volontaire dans les données fournies, et regardez si elle est repérée. C'est le contrôle le plus révélateur, et le plus rarement fait.

Étape 6 — Décider

Quatre issues possibles, et une seule s'appuie sur les quatre mesures de l'étape 4.

—Automatisable : qualité élevée, supervision faible, risque faible, gain de temps net. La tâche peut passer en usage courant avec un contrôle par sondage.

—Assistable : qualité correcte mais supervision nécessaire. L'IA produit la première version, un humain valide systématiquement.

—Accélérable : la qualité ne progresse pas, mais le temps baisse nettement. L'usage se limite aux phases de dégrossissage.

—À conserver humaine : supervision ou risque élevés, ou gain de temps nul ou négatif. La décision est de ne pas déployer — et c'est un résultat, pas un échec.

Écrivez la décision, sa date et les quatre mesures qui la fondent. Vous la relirez au prochain changement d'outil : c'est ce qui vous évitera de refaire le débat sans données.

Ce que ce protocole ne vous dira pas

Il ne classe pas les assistants du marché : un test sur une tâche et un outil ne se généralise pas. Il ne mesure pas un retour sur investissement : il donne un gain de temps sur une tâche, à multiplier par une fréquence que vous seul connaissez. Et il ne remplace pas la question préalable — cette tâche doit-elle continuer d'exister sous cette forme ?

Les limites, clairement

Ce guide reprend la méthode du Lab #1, dont les résultats publiés proviennent d'une campagne simulée. La méthode, elle, est exécutable telle quelle. Un test sur une tâche vaut pour cette tâche : recommencez sur deux ou trois autres avant d'en tirer une règle d'entreprise.