IA en finance : comment distinguer un projet solide d'une promesse

Une direction financière de PME reçoit aujourd’hui plusieurs sollicitations par mois sur l’intelligence artificielle. La difficulté n’est pas le manque d’offres, c’est l’absence de critères permettant de les comparer.

Les propositions se ressemblent : même vocabulaire, mêmes promesses de gain de temps, mêmes ordres de grandeur invérifiables. Voici sept critères qui les départagent, et les signaux qui justifient d’écarter une offre sans aller plus loin.

1. Le point de départ est-il mesuré ?

C’est le critère le plus discriminant, et le plus simple à vérifier.

Demandez comment sera établie la situation actuelle : volumétrie du processus, temps réellement consacré, taux d’erreur constaté, coût complet. Une proposition qui annonce un gain sans avoir mesuré le point de départ annonce un chiffre qu’elle ne peut pas justifier.

Signal d’alerte : un pourcentage de gain communiqué avant tout travail d’observation.

2. Le périmètre est-il délimité ?

Un projet qui se propose de transformer la fonction finance est un projet qui échouera. Non par incompétence, mais parce que le périmètre rend l’échec indétectable jusqu’à ce qu’il soit trop tard.

Un projet solide traite un processus, avec une date de fin et un critère de réussite défini à l’avance.

Signal d’alerte : l’impossibilité d’obtenir une réponse simple à la question « qu’est-ce qui sera précisément en fonctionnement dans trois mois ? »

3. Le coût de fonctionnement est-il chiffré ?

Le coût de mise en œuvre est la partie visible et la plus discutée. Le coût récurrent d’exploitation détermine la rentabilité réelle.

Un dispositif qui consomme des services facturés à l’usage a un coût mensuel qui varie avec le volume traité. Ce coût doit figurer dans la proposition, avec une hypothèse de volume explicite.

Signal d’alerte : un devis qui ne mentionne que le prix du projet.

4. Que se passe-t-il en cas de panne ?

Un traitement automatisé s’interrompt un jour. La question n’est pas de savoir si cela arrivera, mais ce qui se passe à ce moment-là.

Le point critique est la détection. Un dispositif qui s’arrête en produisant une erreur visible est un incident mineur. Un dispositif qui s’arrête silencieusement, alors que les équipes le croient actif, produit une défaillance qui peut durer des semaines.

Signal d’alerte : l’absence de réponse précise sur le mécanisme d’alerte.

5. Que devenez-vous propriétaire ?

À l’issue de la mission, vous devez disposer du code, de la documentation et des accès, dans une forme permettant à vos équipes ou à un autre prestataire de reprendre la main.

Un dispositif dont le fonctionnement dépend d’un abonnement souscrit auprès du prestataire crée une dépendance qui se paiera lors de la renégociation.

Signal d’alerte : une documentation présentée comme optionnelle ou facturée en supplément.

6. Le prestataire sait-il dire non ?

Une part significative des processus soumis à examen relève d’une automatisation classique : moins coûteuse, plus prévisible, plus simple à auditer. Un prestataire compétent le dira.

Un prestataire qui trouve un cas d’usage d’intelligence artificielle dans chacune de vos demandes vend une technologie, pas une solution à votre problème.

Signal d’alerte : aucun arbitrage négatif dans l’ensemble de la proposition.

7. Les données sortent-elles de l’entreprise ?

Certains traitements impliquent la transmission de données à des services tiers, parfois hors Union européenne. Ce n’est pas rédhibitoire, mais cela doit être identifié, écrit, et évalué au regard du RGPD avant l’engagement.

Pour des données financières, comptables ou relatives à des salariés, cette question précède toute discussion technique.

Signal d’alerte : une réponse évasive, ou renvoyée à « la phase technique ».

Les promesses qui devraient vous faire renoncer

Trois formulations méritent un refus immédiat, quelle que soit la qualité apparente du reste :

• un retour sur investissement garanti avant diagnostic, qui suppose une connaissance de vos processus que le prestataire n’a pas ;
• une suppression de postes présentée comme un bénéfice chiffré, qui transforme un projet d’outil en projet social sans en assumer les conséquences ;
• des références clients invérifiables, sans nom, sans secteur, sans possibilité de recoupement.

Sur ce dernier point, l’exigence doit être symétrique. Un prestataire jeune peut légitimement ne pas avoir de références. Ce qui n’est pas acceptable, c’est d’en inventer. Une absence de références assumée, compensée par des éléments vérifiables, vaut mieux qu’une liste de logos que personne ne peut confirmer.

Ce que ces critères ont en commun

Aucun d’eux ne porte sur la technologie. Ils portent tous sur la capacité du prestataire à mesurer, à délimiter, à documenter et à refuser.

C’est cohérent avec ce qu’on observe des projets qui échouent : le problème vient rarement du modèle utilisé. Il vient d’un périmètre trop large, d’un point de départ jamais établi, d’une dépendance non anticipée, ou d’un cas d’usage qui n’aurait jamais dû recevoir cette réponse.