Une démo de ChatGPT commence quand la consigne est prête et se termine au dernier mot de la réponse. Ça prend dix secondes et paraît très productif. Le calcul réel commence au moment où la personne rassemble le contexte et se termine lorsque le résultat est assez fiable pour son usage.

Je décomposerais une tâche en temps observables :

T_total = T_contexte + T_nettoyage + T_prompt + T_attente
        + T_vérification + T_correction + T_intégration + T_reprise

Pour répondre à un courriel complexe, T_contexte peut être déjà payé par une personne qui connaît le dossier. Pour quelqu’un qui reprend le cas, préparer une consigne force une synthèse utile. Le même outil ne crée donc pas le même gain selon l’expertise et le blocage initial.

Un test de productivité doit éviter la meilleure démo choisie après coup. Je sélectionnerais 40 tâches réelles représentatives, nettoyées de données interdites, puis un plan croisé : la moitié des personnes commence avec l’outil, l’autre sans, et on inverse ensuite. Une grille aveugle évalue la qualité finale.

Mesure	Sans assistant	Avec assistant
temps médian complet	18 min	13 min
erreurs factuelles/tâche	0,15	0,35
corrections majeures	8 %	22 %
sorties acceptées sans reprise	70 %	64 %

Ces nombres sont fictifs, mais ils montrent le piège : cinq minutes gagnées peuvent accompagner plus d’erreurs. Il faut pondérer leur gravité. Une tournure moyenne coûte peu; un engagement contractuel inventé peut annuler tout le bénéfice du mois.

Mesurer jusqu’au résultat utilisable

Le protocole suit des étapes fixes :

1. définir la tâche, le critère de réussite et les données permises;
2. échantillonner cas simples, courants et difficiles;
3. enregistrer tout le temps, y compris préparation et vérification;
4. faire évaluer la sortie sans révéler la méthode;
5. classer les erreurs par type et conséquence;
6. compter licences, soutien, formation et intégration;
7. demander si la personne choisirait encore l’outil;
8. répéter après l’apprentissage initial et un changement de modèle.

Le résumé mérite un test particulier. Je prépare des questions dont la réponse se trouve dans les vingt pages, dont une condition qui renverse la conclusion. Un bon résumé doit conserver cette condition et pointer vers sa source. Si la personne doit relire tout le document, l’assistant peut quand même aider à naviguer, mais on ne prétend pas avoir supprimé la lecture.

Le coût technique suit tokens d’entrée/sortie, appels, stockage, surveillance et reprises. Une longue consigne répétée mille fois augmente facture et latence. Un cache est possible pour du contenu public stable, mais jamais en mélangeant les réponses de deux utilisateurs ou versions de document. Les limites de débit demandent une file et un retour à l’ancien processus.

Les erreurs sont conservées dans un jeu de régression. Si un modèle change, je rejoue les cas avant d’élargir. Une panne ne doit pas laisser la tâche coincée dans un état en génération; elle expire, garde le brouillon source et permet la reprise manuelle.

Je ne multiplierais pas « dix minutes par jour » par tous les employés avant ce test. Ma pratique sera de démarrer le chronomètre avant la préparation et de l’arrêter après l’approbation, puis de mettre un prix aux corrections. Le gain existe lorsque qualité, temps complet et risque s’améliorent ensemble, pas lorsque l’animation de génération est rapide.