Le guide d’évaluation de l’IA pour la finance

Présentation

Introduction

Un processus reproductible pour identifier les fonctionnalités qui méritent vraiment leur place dans un flux de travail contrôlé, et quels critères de validation réunir avant d’aller plus loin.

Les fonctionnalités d’intelligence artificielle (IA) doivent mériter leur place dans les flux de travail financiers. Dans ce guide, vous découvrirez comment identifier les cas d’usage viables, valider les allégations des fournisseurs en conditions réelles et évaluer la traçabilité, les contrôles et le budget en production. Les équipes financières y trouveront des outils pratiques pour mettre en œuvre un processus décisionnel documenté, fondé sur des preuves, des responsabilités claires et une amélioration réelle de leurs flux de travail. Voici sept étapes pour partir sur de bonnes bases.

Étape 1

Commencez par la décision, pas par la technologie

Une démonstration montre qu’un logiciel est capable d’arriver à un résultat. Ce qu’elle ne montre pas, c’est la façon dont ce logiciel s’inscrit dans le processus de clôture, de prévision, de rapprochement et de présentation au conseil d'administration. La véritable question est la suivante : « Cette fonctionnalité mérite-t-elle d’intégrer ce processus ? »

Pour l’évaluateur, la réponse n’est pas sans conséquence. La justification d’un écart peut sembler parfaitement pertinente, mais si l’équipe financière ne peut pas faire le lien avec les transactions et comptes sources, alors elle ne pourra pas être exploitée. À l’inverse, une suggestion de rapprochement est un exemple moins impressionnant en apparence, qui peut toutefois offrir une valeur bien réelle. Pour quelles raisons ? Car cette suggestion peut être approuvée par un contrôleur en quelques secondes seulement et que le système enregistre l’identité de la personne qui a approuvé le rapprochement.

Le directeur financier (CFO) doit identifier ces critères de réussite et prendre la décision finale pour les cas d’usage critiques. Ensuite, le test sera principalement mené par les contrôleurs, les responsables comptables, les responsables de la planification et l’analyse financières (FP&A), ainsi que les équipes internes chargées des audits internes, de l’informatique, de la sécurité et des achats. Le CFO n’a pas besoin d’exécuter lui-même le projet pilote, mais il doit identifier les critères qui feront pencher la balance en faveur d’un déploiement avant que ce projet ne soit lancé.

Utilisez une chaîne de valeur en trois étapes

En matière de finance, la valeur de l’IA doit être exploitée dans cet ordre :

Ne passez pas directement du résultat du modèle à la marge, aux recettes ou à sa valeur pour l’entreprise. Même si cela s’avère utile pour justifier une décision, un logiciel n’impacte pas à lui seul les tarifs, les achats, les recrutements ou les activités commerciales. Une étude commerciale qui se contente de relier un résultat produit par l’IA aux performances financières de l’entreprise passe à côté de facteurs essentiels.

Étape 2

Développez une file de cas d’usage

L’IA financière est un ensemble de petites décisions qui impliquent chacune des chiffres et des risques divers. L’opportunité la plus rentable est rarement la plus évidente.

Évaluez chaque candidat grâce à ces cinq questions

Le volume est important : « complexe » et « coûteux » sont deux choses différentes. Une tâche de 30 minutes réalisée 400 fois par mois représente 200 heures de travail. Si elle se déroule six fois par trimestre, cela équivaut cette fois à trois heures de travail. Si une automatisation est toute indiquée dans le premier cas, la seconde situation appelle plutôt à un changement de processus.

• 200 h

  de travail par mois pour une tâche de 30 minutes réalisée 400 fois par mois : une automatisation peut se justifier

• 3 h

  par trimestre pour la même tâche réalisée six fois par trimestre : un changement de processus peut suffire

Le coût de la vérification doit être pris en compte, car il peut effacer un gain supposé. Pour confirmer une proposition de rapprochement, il suffit souvent de comparer les deux montants. À l’inverse, reconstituer le raisonnement à l’origine d’une justification IA et valider son utilisation peut exiger l’intervention d’un analyste expérimenté. L’impact budgétaire peut donc varier significativement.

La complexité des données a aussi des conséquences budgétaires. Chaque nouveau système source, plan comptable, rapprochement manuel et chemin d’exception occasionne un travail de maintenance et d’implémentation supplémentaire. Si l’équipe financière doit préparer l’environnement manuellement en amont, alors ce travail doit être inclus dans l’étude commerciale et non considéré comme une configuration gratuite.

Priorisez les cas d’usage « ennuyeux »

Les commentaires destinés au conseil, d'administration les synthèses et les questions en langage naturel se prêtent bien à l’exercice des démonstrations, car tout le monde peut lire le résultat. Toutefois, la preuve doit être à la hauteur : le résultat est visible, le coût d’une erreur plausible est élevé et une vérification coûte souvent cher.

Les premiers investissements les plus judicieux sont souvent moins glamours :

• Mise en correspondance
• Classification des exceptions
• Détection des anomalies
• Files d’attente d’analyse

Cela s’applique à n’importe quelle tâche à volume élevé pour laquelle une preuve existe déjà et dont une mauvaise suggestion peut être rejetée facilement par un contrôleur.

Étape 3

Transformez les allégations des fournisseurs en hypothèses vérifiables

Une promesse ne mérite votre attention que si l’équipe financière peut la vérifier. Avant de prendre une déclaration pour vérité, demandez à connaître l’opération, la quantité, l’unité, la base de référence, la période, la population et la preuve associées.

Distinguez les indicateurs souvent confondus par les fournisseurs

Demandez-lui aussi quelle technologie réalise l’étape présentée lors de la démonstration. Les règles déterministes, les modèles statistiques et les modèles génératifs ont des faiblesses différentes. Par conséquent, ils n’exigent pas les mêmes éléments de preuve. Un seul produit peut réunir ces trois technologies. Toutefois, l’évaluation doit porter sur le comportement de chaque fonctionnalité, pas sur le produit dans son ensemble.

Étape 4

Réalisez quatre tests avant le déploiement

Chaque projet pilote doit répondre à quatre questions . Chaque question doit s’accompagner d’une réponse disqualifiante définie avant le début des tests.

1. Flux de travail : Le flux de travail est-il défini ?
2. Données : Est-il compatible avec nos données ?
3. Résultat : Le résultat peut-il être justifié ?
4. Contrôles : L’action peut-elle être gouvernée ?

Test 1 : le flux de travail est-il défini et géré ?

Avant la démonstration, rédigez une synthèse d’une page détaillant le flux de travail. Indiquez la tâche, l’utilisateur, le responsable de production, le résultat attendu, la décision en aval, le risque en cas d’erreur et le système associé à ce flux. Le « rapprochement intra-groupe pour les entités de fabrication » est un flux de travail. La clôture n’en est pas un.

Le risque en cas d’erreur détermine le niveau de preuve et les exigences de contrôle. La rédaction de commentaires internes n’exige pas le même contrôle qu’une écriture de journal critique, tout comme une écriture de journal ne doit pas hériter des exigences restreintes appliquées aux commentaires.

Test 2 : les données sont-elles compatibles avec notre environnement ?

Développez l’ensemble du test à partir des conditions réelles de l’entreprise, et non d’un environnement de référence du fournisseur. Intégrez les complications qui freinent habituellement l’automatisation :

• Multiples systèmes
• Différents plans comptables
• Périodes ouvertes et closes
• Révisions
• Devises
• Écritures non rapprochées
• Documents numérisés
• Enregistrements défaillants

Ne donnez pas la solution au fournisseur.

Comptabilisez les pièges, les erreurs et les faux positifs. Loin d’être un indicateur secondaire de qualité, les faux positifs font la différence entre une fonctionnalité qui vous permet de gagner du temps et un outil qui engendre une nouvelle file de corrections en attente. Prenez note de chaque mise en correspondance et chaque étape de pré-exécution manuelle réalisée par le fournisseur. Ne nettoyez pas les données en amont, sauf si le processus en production le fera également.

Test 3 : l’équipe financière peut-elle justifier le résultat obtenu ?

Ne confondez pas réponse, explication, preuve, piste d’audit et reproductibilité. Pour être exploitable, un résultat doit fournir un niveau de preuve à la hauteur du risque associé. Pour les résultats significatifs, l’équipe financière doit pouvoir accéder aux éléments suivants :

• Enregistrements sources
• Opération réalisée
• Écritures significatives et exclusions
• Version du modèle ou des règles
• Historique des contrôleurs
• Preuves suffisantes pour reproduire ou reconstituer le résultat a posteriori

Si la preuve existe uniquement dans l’environnement du fournisseur ou exclusivement sous la version actuelle du modèle, alors la piste d’audit a une date d’expiration. Négociez les droits de conservation et d’exportation avant la signature du contrat.

Test 4 : le système peut-il appliquer le modèle d’exploitation ?

Les contrôles doivent être à la hauteur du champ d’action de la fonctionnalité. Pour les écritures significatives et les résultats de reporting, l’équipe financière a habituellement besoin des éléments suivants :

• Approbation de l’action en amont
• Contrôle adapté des accès
• Enregistrement suffisant pour reconstituer les événements
• Séparation entre la proposition/la configuration et l’approbation

Ces recommandations relèvent de la gouvernance. Il ne s’agit pas d’exigences légales. Les responsables des contrôles internes concernés doivent déterminer leur configuration exacte.

Mettez les contrôles à l’épreuve en demandant au système de faire quelque chose d’interdit. Si la personne qui a configuré le flux de travail n’est pas autorisée à approuver le résultat, essayez de le faire quand même. Le refus du système est une preuve. Une politique écrite n’en est pas une.

Étape 5

Transformez la productivité en décision économique

La principale erreur qui fragilise les études d’opportunité en faveur de l’IA financière consiste à considérer les heures gagnées comme des économies budgétaires. Un projet pilote peut permettre de gagner 200 heures par mois sans pour autant impacter le coût de base. Même si la technologie fonctionne parfaitement, personne n’a encore décidé de ce que l’entreprise allait faire de ce temps gagné.

Évaluez chaque allégation sur le temps gagné selon les quatre niveaux suivants :

La capacité libérée a trois destinations défendables :

Soulager les équipes peut aussi être un choix légitime, en particulier si celles-ci sont surchargées, mais cela doit être clairement annoncé. « Nous avons choisi d’alléger la charge de travail de l’équipe » n’est pas la même chose qu’une promesse d’économies.

Étape 6

Prenez une décision : avancer, corriger ou interrompre

Chaque évaluation doit se terminer par l’une de ces trois décisions, écrites et accompagnées des preuves adéquates.

Un projet pilote réussi sert de preuve à l’échelle testée, pas pour un déploiement dans toute l’entreprise. L’application de la solution à d’autres entités, systèmes, langues ou variantes du processus doit être vérifiée indépendamment. Avant d’aller plus loin, faites au moins un test dans un deuxième environnement choisi pour sa complexité, plutôt que de vous restreindre au cas le plus simple.

Utilisez une fiche d’évaluation pour tous vos projets pilotes

Un projet pilote peut obtenir un score correct dans l’ensemble, mais échouer à cause d’un critère qui rend le déploiement impossible. Utilisez le tableau ci-dessous pour évaluer vos projets et identifier leurs limites. Le score global vous aidera à connaître la force d’un projet, tandis que les critères indispensables au déploiement vous permettront de savoir immédiatement si une initiative est prête à entrer en production. Notez chaque aspect de 0 à 3 :

• 0 = absence de preuve
• 1 = déclaration du fournisseur
• 2 = preuve à l’échelle du projet pilote
• 3 = preuve de vérification par un contrôleur indépendant sans intervention du fournisseur

Un score élevé ne suffit pas. Certains critères doivent être respectés avant de pouvoir déployer une fonctionnalité. Utilisez le score pondéré pour comparer les candidats et les exigences de déploiement, et déterminer si une fonctionnalité est prête à être déployée.

Étape 7

Justifiez la décision

Les conseils et comités d’audit évaluent la décision de l’équipe de gestion :

• Qu’est-ce que cette fonctionnalité permet d’accomplir et quelles sont ses limites ?
• Quel est l’impact sur l’environnement de contrôle ?
• Qui est responsable du résultat ?
• Quelle est la valeur démontrée ?
• Quels éléments pourraient freiner ou interrompre le déploiement ?

Si le projet passe à la phase suivante, répondez à quatre questions :

• Portée : que fait cette fonctionnalité et qu'est-elle incapable de faire ?
• Contrôle : où intervient l’approbation humaine et qu’est-ce que le système permet d’empêcher ?
• Valeur : quel est le bénéfice net à l’échelle testée (pas l’estimation du fournisseur ni les heures brutes) ?
• Suivi : le responsable, la cadence, le risque résiduel et l’interruption ou la condition de rollback ont-ils été définis ?

Dans le cas d’une interruption, commencez pas le facteur disqualifiant

Énoncez la décision (ne décrivez pas l’intégralité du projet pilote), la preuve qui rend le déploiement inenvisageable, si une tâche restreinte peut perdurer et le coût de l’évaluation. Plus qu’une preuve d’échec du programme d’IA, un projet pilote interrompu est la preuve que le cadre d’évaluation fonctionne.

Dans le cas d’un déploiement restreint, détaillez l’échelle définie

Énoncez ce qui est inclus et exclus, pourquoi ces restrictions existent et les preuves nécessaires pour étendre cette limite. Évitez toutefois d’étendre la portée pendant la réunion, au risque qu’un projet pilote contrôlé ne devienne une dépendance non gouvernée.

Conclusion

Conclusion

Ce guide s’appuie sur une idée simple : l’IA doit être évaluée au même titre que tout autre investissement.

Au lieu d’évaluer la capacité d’une fonctionnalité à vous impressionner, demandez-vous si elle améliore vos flux de travail, produit des résultats fiables et offre une valeur mesurable. Les bonnes décisions sont fondées sur des preuves, pas sur des démonstrations. Cela implique de comprendre où intégrer une fonctionnalité, quelles sont ses limites et quels contrôles sont requis avant de passer en production.

Le résultat de l’évaluation doit être clair. Si certains cas d’usage peuvent être déployés à grande échelle, d’autres exigeront un champ d’application restreint, des tests supplémentaires, voire seront totalement interrompus. Faire preuve de discipline est un atout, pas une faiblesse. Le service financier doit appliquer les mêmes exigences à chaque projet pilote pour investir dans les bonnes fonctionnalités : celles qui résolvent des problèmes réels, favorisent la prise de décisions et répondent aux besoins, même lorsque l’enthousiasme de la première démonstration est retombé.