Modèle
Suivi des essais avec l'IA
Consignez les résultats, le temps de vérification et la prochaine action.
Choisissez une période de suivi adaptée
Utilisez cette fiche pour une pratique individuelle ou un pilote d'équipe. Un suivi hebdomadaire peut être utile ; aucun calendrier de douze semaines n'est imposé. Notez les faits au moment où ils se produisent et ne conservez que les informations dont le partage et la conservation sont autorisés.
Pour une pratique individuelle, indiquez votre tâche et la suite. Pour un pilote d'équipe, ajoutez le relecteur et la personne habilitée à approuver les modifications des systèmes partagés. Une proposition n'est pas une décision approuvée.
Comparez temps et qualité
| Période / tâche | Tentatives / résultats acceptés | Temps de travail | Qualité et incidents | Ressources | Action / responsable |
|---|---|---|---|---|---|
| [Dates et périmètre] | [Nombre et critères] | [Avant / avec IA] | [Vérifications, corrections, cas inachevés] | [Préparation, coûts, inconnues] | [Proposition ou décision approuvée, échéance] |
Incluez préparation, modifications du prompt ou du Skill, vérification, corrections, tentatives échouées et transmission. Détaillez la configuration initiale pour ne pas l'omettre ou la compter deux fois. Comparez des entrées similaires avec les mêmes limites de mesure.
Qualifiez chaque chiffre : mesuré, estimation personnelle, hypothèse ou inconnu, avec sa source. Terminer le programme ne prouve pas son utilisation au travail : notez qui l'utilise, à quelle fréquence et avec quelle aide.
Exemple E1
Données illustratives de E1, pas d'une exécution observée :
| Élément | Entrée |
|---|---|
| Périmètre | Quatre cas ; 2/3 participants ont pratiqué sans aide |
| Temps | Avant : 40 minutes ; avec IA : 32 minutes |
| Qualité | Avant : 4/4 acceptés ; avec IA : 3/4 |
| Ressources | API : 0.24 USD ; préparation/tests : 30 minutes ; autres coûts non fournis |
| À vérifier | E04 arrêté sans résultat accepté ; données renvoyées à vérifier |
| Proposition | Maintenir le parcours concerné en pause ; IT vérifie les données et ne corrige qu'un défaut confirmé ; Lan refait les tests ; le responsable métier décide de la reprise |
L'écart de temps de 20% ne démontre pas un gain de productivité : le travail achevé n'est pas équivalent. N'en déduisez ni ROI ni économie financière.
Séparez les tests de sécurité
Un refus exigé par les droits d'accès peut réussir un test de sécurité sans produire un résultat métier complet. Un résultat inachevé ou non vérifié n'est pas accepté. Définissez les deux critères avant les tests.
| Événement / date | Faits / inconnues | Périmètre en pause | Responsable de l'enquête | Nouveau test et décision de reprise |
|---|---|---|---|---|
| [Référence] | [Confirmé / à vérifier] | [Parcours concerné] | [Responsable] | [Preuves, décision autorisée et état] |
Une tentative non autorisée ne prouve pas une divulgation. Vérifiez les faits avant de conclure à une fuite, une infraction ou un incident maîtrisé.
Copiez pour la prochaine revue
Période / tâche / périmètre individuel ou d'équipe :
Version du prompt, Skill ou workflow ; sources pertinentes :
Tentatives / résultats acceptés / critères :
Cas de sécurité / comportement attendu / observé :
Temps avant et avec IA, mêmes limites de mesure :
Configuration ; vérification, corrections et tentatives échouées :
Coûts des outils / estimations / inconnues :
Mesuré, estimé ou supposé / source :
Utilisateurs réels, fréquence et aide :
Problèmes confirmés / inconnues :
Proposition ou décision approuvée / état d'approbation :
Action / responsable / échéance / contrôle :
Vérifiez comparabilité, qualité, effort total, coûts et incidents avant de poursuivre, modifier, suspendre ou arrêter. Utilisez ces traces dans le bilan, sans reconstituer les résultats de mémoire.