Retour aux articles

L’IA générative est entrée dans les entreprises par la porte de l’expérimentation. Un assistant qui résume des comptes rendus, un modèle qui propose une écriture, une preuve de concept lancée par une équipe curieuse. Puis vient le mur : passer de la démonstration séduisante à un usage qui tient dans la durée, qui s’audite et qui se mesure.

Dans la fonction Finance, ce passage est plus exigeant qu’ailleurs. Les données sont sensibles, les processus sont contrôlés, et une erreur ne se rattrape pas avec un « bêta ». C’est précisément parce que l’exigence est haute que S/4HANA et l’IA forment un couple cohérent : l’un apporte le socle, l’autre l’accélérateur.

Le socle d’abord : sans données fiables, pas d’IA crédible

Un modèle d’IA ne rattrape jamais une donnée douteuse : il l’amplifie. C’est la première leçon des projets qui réussissent. Avant de parler d’agents, il faut répondre à des questions simples : où vit la donnée financière, qui la détient, à quelle fréquence est-elle rafraîchie, et peut-on la tracer jusqu’à sa source ?

• Une source unique de vérité : le référentiel de comptes, les centres de coûts, les axes analytiques. Si deux services calculent deux marges, aucune IA ne les réconciliera.
• Une qualité mesurée : un tableau de bord de la qualité des données (complétude, cohérence, fraîcheur) avant de déployer le premier cas d’usage.
• Une traçabilité de bout en bout : chaque chiffre doit pouvoir remonter à son écriture d’origine. C’est la condition d’un contrôle interne qui tient.

Trois cas d’usage qui tiennent leurs promesses

1. La clôture assistée

Le rapprochement des comptes, la détection des écritures inhabituelles, la préparation des justificatifs : autant de tâches répétitives, à fort volume et parfaitement cadrées. Un copilote qui propose, et un contrôleur qui valide. Le gain ne vient pas du temps gagné sur une tâche, mais du fait qu’on ne découvre plus les anomalies trois jours avant la publication.

2. Le pilotage conversationnel

« Quel est l’écart sur la masse salariale du site de Lyon, et depuis quand ? » Posée en réunion, cette question prend aujourd’hui vingt minutes de recherche et deux extractions. Adossée à un socle fiable, elle devient une réponse en quelques secondes, avec le détail du calcul. L’enjeu n’est pas de parler à un modèle : c’est que le chiffre affiché soit le bon, et qu’il soit traçable.

3. Le contrôle continu

Au lieu de contrôler par échantillon en fin de mois, on contrôle en continu, sur l’ensemble des flux. Les écarts remontent au fil de l’eau, quand il est encore possible d’agir. C’est le changement le plus profond : le contrôle cesse d’être un exercice de constat pour devenir un outil de pilotage.

Ce qui fait échouer la plupart des projets

Trois causes reviennent presque toujours, et aucune n’est technique.

1. Le cas d’usage trop large. « Transformer la fonction Finance par l’IA » n’est pas un cas d’usage. « Réduire d’un tiers le temps de préparation des justificatifs de clôture » en est un.
2. Le pilote sans propriétaire. Une équipe curieuse lance une preuve de concept, personne n’en porte la suite dans les processus. À la fin du pilote, le modèle s’éteint avec l’enthousiasme de son auteur.
3. La conformité traitée à la fin. L’AI Act, la protection des données, la traçabilité des décisions automatisées : ce ne sont pas des cases à cocher une fois le système en production, mais des contraintes de conception.

Par où commencer, concrètement

La trajectoire qui fonctionne tient en quatre mouvements, et elle se déroule sur des mois, pas des semaines.

• Cadrer une décision et un indicateur de succès mesurable.
• Consolider le socle de données sur le périmètre de cette décision, pas sur l’ensemble du groupe.
• Déployer un premier cas d’usage étroit, avec un propriétaire nommé côté métier et un dispositif de contrôle.
• Industrialiser : la gouvernance, la mesure, et le passage à l’échelle seulement une fois la valeur démontrée.

Retour aux articles