01 — Problème de recherche
La comparaison internationale se fragmente lorsque chaque marché possède son propre format.
Les études locales produisent des informations riches, mais leurs formats, langues et niveaux de synthèse varient. Un enseignement remonté en Pologne peut être formulé, classé et archivé différemment d’une observation faite au Portugal. L’équipe centrale consacre alors une part importante de son temps à harmoniser les livrables avant de pouvoir comparer les résultats.
J’ai formulé le problème comme une chaîne de transformation reproductible. L’objectif consistait à réduire le travail mécanique de transcription, traduction, reformulation et classement tout en conservant la source, le marché, la sévérité et le contexte de chaque observation.
02 — Parti pris
Construire un outil fonctionnel pour tester le contrat entre l’équipe et l’intelligence artificielle.
Le prototype accepte trois points d’entrée : verbatim, audio et avis publics. L’audio est transcrit. Le service d’analyse de l’application traite le verbatim original sans traduction préalable ; le pipeline en ligne de commande dispose, lui, d’un module de détection, traduction et glossaire. L’extraction libre ou guidée structure les réponses dans les mêmes champs.
La sortie est contrainte par un schéma JSON — JavaScript Object Notation, un format de données structuré — qui impose les mêmes champs à chaque réponse : thème, sévérité, enseignement, recommandation, provenance, marché et éventuelle tendance commune à plusieurs marchés.
03 — Produit de recherche
La base partagée conserve les résultats et leurs sources dans un format commun.
Chaque résultat peut être relu, modifié, filtré par marché, source ou thème et relié à la donnée d’origine. Une bibliothèque de questions et de groupes permet de réutiliser une grille d’entretien. Un tableau de contrôle agrège les études et affiche le délai moyen avant synthèse ainsi que les thèmes récurrents.
Le système couvre quatre marchés, quatre connecteurs de sources, deux modes d’analyse et quatre thèmes principaux. Le prototype montre qu’une équipe peut conserver une méthode commune sans imposer un même canal de collecte à tous les pays.
04 — Portée
L’automatisation prépare la comparaison ; la validation reste une étape de recherche.
Le modèle prépare une première structuration éditable. La revue des formulations, de la sévérité et des recommandations reste nécessaire avant utilisation ; le prototype ne comporte pas de verrou imposant cette validation avant diffusion. Le temps économisé et la qualité de la revue sont des objectifs à mesurer.
Pour une équipe ResearchOps, la suite logique consiste à mesurer l’accord entre chercheurs, le temps réellement économisé, la qualité des traductions par marché et la proportion d’extractions corrigées. Ces indicateurs permettent d’évaluer le système comme un véritable outil de recherche.
05 — Du concept à la décision
Un schéma identique ne garantit pas un sens identique.
Imaginez deux retours : « Je ne sais pas ce qui se passe après validation » et « Je voudrais pouvoir annuler ». Ils peuvent relever du même thème, tout en suggérant des actions différentes. Le premier appelle une information sur la suite ; le second, un contrôle réversible.
Pour évaluer le prototype, je comparerais les extractions avec celles de chercheurs, conserverais les désaccords et mesurerais le temps de relecture. La valeur du système serait la qualité de la synthèse obtenue après correction, avec une provenance facile à retrouver.