Pourquoi les données financières ne suffisaient-elles pas ?
Le responsable de la planification décrit une première phase décevante : l’équipe dispose de données connectées mais reçoit des commentaires peu utiles, parfois incohérents. Le modèle ne connaît pas suffisamment la stratégie, les objectifs, les indicateurs, les projets en cours ou les règles de prix de l’entreprise.
Une donnée peut être exacte tout en restant difficile à interpréter. Pour expliquer une variation de coût, il faut comprendre les changements d’organisation, les choix de localisation ou les priorités du moment. La session présente cette connaissance métier comme une couche distincte des chiffres et du moteur de calcul.
Comment Uberall a-t-il structuré ce contexte métier ?
L’équipe décrit un dépôt GitHub contenant des fichiers de contexte et des instructions. Elle recommence ensuite l’exercice avec les mêmes données, le même modèle et les mêmes questions. L’intervenant rapporte une amélioration nette de la valeur des réponses et donne l’exemple d’une analyse des coûts de personnel éclairée par la stratégie de localisation.
La présentation distingue des analyses locales rapides et des usages récurrents distribués plus largement. Ces derniers demandent une gouvernance des données et des droits. Les calculs structurés et auditables restent portés par le système de planification ; l’IA aide à construire, explorer et expliquer les analyses.
Documenter une règle et son périmètre
Pour transposer la méthode, une équipe peut décrire une métrique, sa formule, sa période et ses exclusions. Elle précise aussi qui peut consulter les données sous-jacentes. Ce travail pédagogique rend le contexte testable ; il ne constitue pas la liste exacte des fichiers utilisés par Uberall.
Quels résultats sont confirmés par chaque source ?
La transcription confirme la comparaison à données, modèle et questions identiques et une amélioration qualitative déclarée. Les pourcentages figurent dans le recap AISB26 fourni séparément, mais ne sont pas prononcés dans la transcription disponible. Cette différence de source doit rester visible.
| Résultat rapporté | Source | Limite |
|---|---|---|
| Réponses plus utiles après ajout du contexte | Use Case 12, témoignage Uberall | Appréciation qualitative sans protocole détaillé |
| 60 % de réponses insatisfaisantes au départ | Recap AISB26, version de travail | Taille du test et définition non documentées |
| Plus de 95 % de réponses correctes ensuite | Recap AISB26, version de travail | Chiffre absent de la transcription consultée |
| Même modèle, mêmes données, mêmes questions | Use Case 12 | Comparaison déclarée, non reproduite indépendamment |
Quelles limites conserver avant de généraliser ?
Le corpus ne fournit pas le jeu de questions, les évaluateurs, la méthode de notation ou le nombre d’essais. Les pourcentages du recap ne doivent donc pas devenir un benchmark universel ni une promesse de précision. La source des valeurs doit être confirmée, par exemple avec les supports de présentation, avant publication définitive.
Le contexte ne remplace pas la gestion des droits. La session insiste sur la différence entre une analyse dans l’équipe finance et sa diffusion à un ensemble plus large de salariés. Une information utile pour expliquer un coût peut contenir des données individuelles qui ne doivent pas être exposées à tout le monde.
Quelles compétences une équipe finance peut-elle travailler ?
Un exercice peut commencer avec une question récurrente et des données fictives. Les participants rédigent les définitions métier puis comparent les réponses avant et après leur ajout, en conservant une grille stable : formule, période, hypothèses, exclusions et informations manquantes. Les résultats décrivent seulement ce test.
Il faut ensuite séparer le calcul de son commentaire, vérifier les totaux avec un outil adapté et demander l’origine des explications. Un responsable doit maintenir les règles et retirer les versions obsolètes. La compétence recherchée est la préparation d’un contexte utile et contrôlable, pas l’accumulation de documents.
