Un jeu de données dont on connaît le résultat attendu
Le lot comprend 100 demandes valides, 10 copies de demandes existantes, 5 adresses incomplètes et 5 budgets négatifs. Les identifiants DEMO et les adresses example.invalid sont fictifs. Les 100 demandes valides se répartissent à égalité entre SEO, SEA, web et automatisation.
Le résultat attendu est défini avant l’exécution : 100 demandes acceptées, 10 doublons écartés et 10 rejets documentés. La vérification des adresses est volontairement simple et ne contrôle pas la délivrabilité d’un e-mail. Le programme ne contacte aucun destinataire et ne crée aucun dossier dans un CRM.
Mesurer le traitement plutôt que promettre un gain humain
Après cinq passages de préparation, le navigateur réalise quinze séries de cent traitements du même lot. Le temps de chaque série est divisé par cent pour obtenir une durée moyenne par lot. Nous publions ensuite la médiane des séries, leur 95e percentile et les valeurs brutes. Le regroupement rend les très courtes durées moins sensibles à la précision de l’horloge.
Ces durées couvrent les validations, le dédoublonnage et la répartition en mémoire. Elles ne couvrent ni la saisie, ni la lecture humaine, ni un appel réseau, ni la création du téléchargement. Aucun gain de temps de salarié n’est affirmé : il faudrait chronométrer le même processus avec une personne et inclure le contrôle des exceptions.
Les erreurs font partie du résultat
Chaque ligne rejetée garde son identifiant et son motif. Une automatisation exploitable doit permettre de corriger une donnée, de comprendre un rejet et de rejouer une demande sans créer de doublon. Le rapport expose le résultat du contrôle de conformité attendu avant de parler de vitesse.
Cette expérience utilise des règles explicites et fonctionne localement. Elle n’évalue pas un modèle d’intelligence artificielle. Un projet connecté à vos outils demandera un cadrage supplémentaire des accès, des formats, des reprises après erreur et des responsabilités de validation.