← Le travail réellement délégable à l'IA

Méthodologie — protocole v1.3

Publié le 23 août 2026, avant toute collecte. Signé par David Licoppe. Édition signée par David Licoppe, fondateur de Youpi News. Le nom de l'évaluateur est enregistré expérience par expérience.

Question de recherche

Qu'est-ce que l'IA peut réellement prendre en charge dans le travail quotidien d'une PME, dans quelles conditions, avec quel niveau de supervision et avec quelles limites ?

Ce que cette expérimentation ne cherche pas à établir

Désigner « le meilleur assistant IA » : aucun score global d'assistant ne sera publié comme conclusion.
Démontrer que l'IA est utile : nous cherchons à déterminer dans quelles conditions elle l'est.
Évaluer des modèles sur des jeux de tests académiques : nous testons des tâches de travail réelles.

Hypothèses de départ

Le résultat dépend davantage de la qualité du contexte fourni que de l'assistant choisi.
Le temps de contrôle et de correction humaine détermine le gain réel, pas la vitesse de production.
Certaines tâches sont accélérables sans être délégables : la décision et la responsabilité restent humaines.
La reproductibilité d'un résultat est une condition d'usage professionnel, distincte de sa qualité.

Périmètre

20 tâches issues du travail quotidien d'une PME, définies avant la collecte.
5 assistants grand public, dans leur formule réellement utilisée, produit et version enregistrés.
3 modes d'utilisation par tâche et par assistant : usage spontané, contexte structuré, interaction.
Mêmes données d'entrée, même objectif, même livrable et même grille de qualité pour les trois modes d'une tâche.
20 baselines humaines : une baseline mesurée pour chacune des tâches T01 à T20, sur les mêmes données et le même livrable.
300 expériences principales, complétées par un maximum de 60 rejeux qui ne comptent pas dans cette couverture.

Règles d'évaluation

Les quatre notes sont bornées 0–5 et chaque métrique possède ses propres ancres : un score élevé n'a pas le même sens pour la qualité et pour le risque.
La grille de qualité de chaque tâche est écrite avant la collecte et n'est pas ajustée en cours de route.
Chaque tâche possède une grille spécifique (docs/lab/01/TXX/evaluation-rubric.md, version 1.1) : socle commun de cinq critères, puis vérité de terrain, éléments acceptables, pièges, erreurs mineures / majeures / critiques, règles de calcul, contraintes de forme mesurables, pondération et capacités additionnelles.
La pondération des cinq critères dépend de la famille de la tâche : exactitude et absence d'invention en analyse et décision, gestion de l'incertitude et détection de problème en processus et limites, fidélité aux entrées et utilité opérationnelle en production et marketing. Les cinq critères restent notés dans tous les cas.
La même grille, socle commun et section spécifique, s'applique aux modes A, B et C ainsi qu'à la baseline humaine de la tâche.
Une erreur critique plafonne la qualité : un livrable contenant une information inventée n'est pas utilisable.
Le prompt exact, le contexte fourni et la sortie brute sont conservés pour chaque expérience.
L'évaluation est réalisée à l'aveugle lorsque c'est techniquement possible et méthodologiquement pertinent ; à défaut, la raison est enregistrée avec l'expérience.
Toute valeur non mesurée est enregistrée comme inconnue, jamais remplacée par une valeur par défaut.
Chaque affirmation publiée porte son niveau de preuve : FAIT, ANALYSE ou EXPÉRIMENTATION.

Règles de verdict

AUTOMATISABLE — qualité suffisante, supervision faible, reproductibilité élevée, risque faible.
ASSISTABLE — résultat utile mais contrôle humain systématique nécessaire avant usage.
ACCÉLÉRABLE — le gain porte sur le temps de démarrage ou de mise en forme, pas sur le fond.
PEU PERTINENT — le gain net est nul ou négatif au regard du temps de préparation et de contrôle.
À CONSERVER HUMAIN — la responsabilité, le jugement ou le risque interdisent la délégation.
Le verdict croise qualité, temps humain total, erreurs, supervision, reproductibilité et risque. La qualité seule ne décide jamais.

Baseline humaine

La baseline est un point de référence expérimental propre à chaque tâche : une exécution humaine réelle, unique et documentée dans les conditions du protocole.
Elle n'est jamais présentée comme « la performance moyenne d'un humain » ni comme « la performance humaine de référence ».
Aucune optimisation artificielle de la baseline n'est autorisée, ni en faveur ni en défaveur des assistants : l'exécutant travaille dans ses conditions habituelles.
Le profil de l'exécutant, son rôle, son niveau d'expérience, les outils autorisés et réellement utilisés, les conditions et les interruptions sont tracés.
Chaque tâche porte son protocole de baseline versionné : docs/lab/01/TXX/baseline.md.
Les cinq phases sont chronométrées séparément : préparation, production, contrôle, correction, finalisation. Le temps humain total est calculé, jamais saisi.
Toute interruption arrête le chronomètre : nombre, durée et phase sont consignés séparément et ne sont jamais intégrés au temps humain.
Chaque baseline porte un statut : planifiée, réalisée, impossible ou invalidée.
Une baseline humaine est réalisée pour chacune des 20 tâches : la couverture attendue est de 20/20.
Mêmes données, même objectif, même livrable et même grille de qualité que les expériences.
Sont enregistrés : personne, rôle, date, conditions, temps détaillés, temps de référence, qualité critère par critère et limites.
La baseline est réalisée avant consultation des sorties IA lorsque c'est possible ; sinon la raison est documentée.
Une baseline impossible reste nulle et porte une justification écrite explicite : elle n'est jamais remplacée par une valeur estimée, par une moyenne, ni par la baseline d'une autre tâche.
Non-substitution : la baseline d'une tâche ne sert de référence à aucune autre tâche.
Aucune baseline n'est estimée : sans mesure, la tâche n'a pas de référence et aucun gain n'est publié.

Reproductibilité et rejeux

Le protocole est versionné : toute modification produit une nouvelle version et est journalisée.
Chaque expérience conserve la version du protocole et la version de la fiche tâche utilisées.
La campagne comporte 300 expériences principales et jusqu'à 60 rejeux, soit environ 20 % des expériences principales.
Les rejeux sont répartis de manière équilibrée entre tâches, modes et assistants, et sélectionnés après les premières expériences.
Un rejeu est enregistré comme expérience distincte, liée à l'expérience d'origine (`replayOf`), avec la même tâche, le même mode, les mêmes données et une nouvelle session.
Un rejeu ne compte jamais dans la couverture des 300 expériences principales : le champ `isReplay` est la seule source de vérité, indépendamment du statut de l'expérience.
Un changement majeur de modèle ou de fonctionnalité déclenche une nouvelle version expérimentale, pas un simple rejeu.
La méthodologie est publiée pour permettre à un tiers de reproduire l'expérimentation.

Traçabilité

Chaque expérience porte l'identifiant officiel `L1-T01-A-CHATGPT-001` : édition, tâche, mode, assistant, numéro de séquence.
L'environnement d'exécution est enregistré : interface utilisée, navigation web, outils activés, dépôt de fichiers, mémoire, région éventuelle.
Le modèle et la version réellement utilisés sont consignés au moment du test, jamais reconstitués après coup.
Le nombre de tours est enregistré pour chaque expérience.
Le prompt de référence de la tâche est cité (`prompt-A.md`, `prompt-B.md`, `prompt-C.md`) ; toute adaptation du prompt est signalée et justifiée.
Les entrées synthétiques sont signalées comme telles et ne sont jamais présentées comme des données d'entreprises réelles.
Chaque expérience porte un statut : planifiée, réalisée, invalidée ou rejouée. Une expérience invalidée porte sa raison et n'entre dans aucune agrégation.
Les sorties brutes ne sont pas embarquées dans le site : chaque expérience porte une référence d'archive `lab-01/raw/<identifiant>/` contenant prompt, entrées, sortie et métadonnées.
Les tâches disposent d'un dossier expérimental reproductible versionné dans le dépôt : `docs/lab/01/TXX/`.

Règles de coût

Coût direct, coût d'accès et coût humain sont enregistrés séparément.
Aucun coût par tâche n'est déduit d'une division arbitraire du prix d'un abonnement.
En édition 1, le coût humain opérationnel reste inconnu : aucun taux horaire n'est déclaré.
Les temps restent mesurés et exploitables indépendamment de toute valorisation financière.
Un coût publié est toujours accompagné de sa méthode de calcul.

Limites assumées

Les modèles évoluent : les résultats sont datés et valent pour les versions enregistrées.
Les baselines humaines sont des références expérimentales mesurées dans nos conditions, et non des moyennes de marché.
20 tâches ne couvrent pas l'ensemble du travail d'une PME : elles en couvrent des situations fréquentes.
Les résultats dépendent de la qualité des données d'entrée que nous fournissons.
Les mesures de temps portent une part d'imprécision inhérente à l'observation d'un travail réel.
L'évaluation est réalisée par un nombre restreint d'évaluateurs, ce qui limite la portée statistique des notes.
L'aveugle n'est pas toujours possible : lorsqu'il ne l'est pas, un biais de marque résiduel ne peut être exclu.

Échelles de notation 0–5 : un score élevé n'a pas le même sens selon la métrique

Métrique	0	5	Lecture
Qualité	0 — livrable inutilisable	5 — livrable directement exploitable	Un score élevé est favorable : plus la note est haute, plus le livrable est utilisable en l'état.
Supervision nécessaire	0 — aucune intervention humaine nécessaire	5 — intervention humaine très importante	Un score élevé est défavorable : plus la note est haute, plus le travail humain de contrôle et de reprise est important.
Reproductibilité	0 — résultat très instable d'une exécution à l'autre	5 — résultat très stable et reproductible	Un score élevé est favorable : plus la note est haute, plus le résultat est stable au rejeu.
Risque	0 — risque négligeable en cas d'erreur non détectée	5 — risque critique en cas d'erreur non détectée	Un score élevé est défavorable : plus la note est haute, plus la conséquence d'une erreur non détectée est grave.

Ce qui ne pourra jamais être conclu à partir de cette expérimentation

Qu'un assistant est « meilleur » dans l'absolu.
Que les résultats valent pour toutes les PME.
Qu'une tâche est toujours automatisable.
Que l'IA remplace un métier.
Qu'un résultat obtenu aujourd'hui sera identique dans six mois.
Qu'un gain observé sur une tâche s'applique à toutes les tâches.

Les conclusions publiées resteront proportionnées au protocole.

Volumétrie attendue

300 expériences principales.
Jusqu'à 60 rejeux, hors couverture des 300 expériences principales.
20 baselines humaines, une par tâche.

Métriques enregistrées

Métrique	Définition	Obtention
Qualité	Note bornée 0–5 selon la grille de critères propre à la tâche, écrite avant la collecte. 0 = livrable inutilisable, 5 = livrable directement exploitable.	evaluation
Temps de préparation humaine	Temps passé à réunir, structurer et formuler la matière avant la demande.	mesure
Temps de production	Temps d'obtention du résultat, échanges compris.	mesure
Temps de contrôle humain	Temps nécessaire pour vérifier le résultat et détecter les erreurs.	mesure
Temps de correction	Temps de reprise des erreurs et manques identifiés.	mesure
Temps de finalisation	Temps de mise au format du livrable réellement utilisable.	mesure
Temps humain total	Somme des temps humains : préparation + contrôle + correction + finalisation. Calculé, jamais saisi.	calcul
Gain opérationnel net	Temps humain de référence (baseline de la tâche) moins le temps humain total nécessaire avec l'assistant. Non calculable sans baseline mesurée pour la tâche.	calcul
Coût direct	Coût mesurable de l'exécution : consommation facturée, appels payants.	mesure
Coût d'accès	Coût documenté de l'accès à l'outil sur la période, sans répartition arbitraire.	mesure
Coût humain opérationnel	Valorisation du temps humain. Non calculée en édition 1 : aucun taux horaire n'est déclaré, la valeur reste inconnue.	calcul
Erreurs	Comptage séparé des erreurs mineures (forme), majeures (fond corrigeable) et critiques (inexactitude, invention, risque).	evaluation
Supervision nécessaire	Niveau de contrôle humain requis pour que le résultat soit utilisable, borné 0–5. 0 = aucune intervention nécessaire, 5 = intervention humaine très importante.	evaluation
Reproductibilité	Stabilité du résultat pour une même demande, bornée 0–5 et vérifiée par rejeu. 0 = très instable, 5 = très stable.	evaluation
Risque	Conséquence d'une erreur non détectée (relation client, conformité, décision, confidentialité), bornée 0–5. 0 = risque négligeable, 5 = risque critique.	evaluation
Nombre de tours	Nombre d'échanges entre l'expérimentateur et l'assistant. Attendu à 1 en modes A et B, enregistré tel quel en mode C.	mesure
Verdict	Classement de la tâche selon plusieurs dimensions, pas selon la seule qualité.	evaluation

Versions du protocole

v1.0 — 2026-08-23Publication du protocole initial : 20 tâches, 5 assistants, 3 modes, métriques, règles d'évaluation, de verdict, de baseline, de coût et de reproductibilité.
v1.1 — 2026-08-23Alignement sur le protocole d'exécution officiel : identifiants L1-TXX-MODE-ASSISTANT-NNN, bornes 0–5 avec ancres propres à chaque métrique, traçabilité complète de l'environnement, nombre de tours, 20 baselines attendues, évaluation à l'aveugle documentée, 300 expériences principales et jusqu'à 60 rejeux hors couverture, dossiers expérimentaux docs/lab/01/TXX/, signalement des données synthétiques, statut d'expérience et publication intégrale des limites.
v1.2 — 2026-08-23Correction méthodologique du corpus : grilles d'évaluation spécifiques à chaque tâche (vérité de terrain, éléments acceptables, pièges, erreurs mineures / majeures / critiques, règles de calcul, contraintes observables, pondération par famille, capacités additionnelles), mode C reformulé en exigence sémantique avec procédure mono-tour et conversationnelle et mesure descriptive des tours, protocoles de baseline versionnés pour les 20 tâches avec chronométrage en cinq phases, interruptions consignées, non-substitution et null justifié, statut de baseline, entrées enrichies pour T01/T05/T12, livrables durcis pour T08/T09/T11/T18, et statut définitif de l'anomalie de juin de T02.
v1.3 — 2026-08-23Orchestration de la campagne : matrice déterministe de 300 cellules attendues strictement séparée du registre des expériences réellement exécutées, journal d'exécution dérivé, identifiants d'expérience et de rejeu générés, gel du protocole et du corpus dès la première expérience réalisée, double évaluation d'un sous-échantillon de 30 expériences avec calcul et publication des écarts, statut de coût explicite, complétude et champs manquants déclarés, cochages de vérité de terrain, détection d'anomalie et distinction formelle entre baseline mesurée et référence humaine estimée.

Traçabilité de l'exécution

Chaque expérience prévue possède une fiche d'exécution qui renvoie au dossier de la tâche : prompt du mode, jeu d'entrée, livrable attendu, grille d'évaluation. Ces fiches sont des documents de référence dérivés de la matrice ; elles ne contiennent aucun résultat et ne comptent jamais comme une expérience réalisée.

Cellules planifiées: 300 / 300
Expériences enregistrées: 0 / 300 — aucune donnée mesurée
Rejeux enregistrés: 0
Corpus de référence: docs/lab/01/

Chaîne de traçabilité : tâche → prompt du corpus → identifiant d'expérience → archive de la sortie brute → registre. Les archives brutes sont conservées hors du site.