Réussir la mise en œuvre de l'IA

La plupart des projets d'IA n'échouent pas à cause de la technologie. Ils échouent au niveau du deuxième cas d'utilisation, c'est-à-dire lorsque le premier a fonctionné et que personne ne sait comment l'appliquer au processus suivant.

Tous ceux qui ont déjà vécu cette situation connaissent bien ce scénario : le traitement des factures est en cours, l'équipe est satisfaite, les chiffres concordent. Six mois plus tard, cette même technologie doit lire des bons de livraison. Et le projet repart de zéro, car le modèle, les seuils et le processus de vérification avaient été conçus pour un seul et unique type de document.

Le groupe d'assurance AXA en a tiré les conséquences. Le groupe met fin à ses expériences décentralisées en matière d'IA et a mis en place, en collaboration avec Publicis Sapient, un „ Global AI Hub “ indépendant des fournisseurs, comme Tristan Fincken dans *Computerwoche* comme l'a rapporté le 11 septembre 2026. Les trois domaines d'intervention de la plateforme sont révélateurs : le traitement des e-mails clients, la gestion des sinistres automobiles et la gestion des connaissances à l'échelle de l'entreprise. Tous trois reposent sur des documents et ont besoin de la même base.

Cet article répond à la question sous-jacente : comment mettre en œuvre l'IA de manière à ce qu'elle puisse évoluer au-delà de son premier cas d'utilisation ?

Pourquoi la mise en œuvre de l'IA se limite-t-elle si souvent à un projet pilote ?

Les chiffres à ce sujet sont récents et d'une clarté inhabituelle. Le prestataire de services informatiques Kyndryl a, pour le Rapport sur l'état de préparation des personnes 2026 1 100 responsables techniques et technologiques interrogés dans huit pays, et publication des résultats le 25 juin 2026. Le fait qu'un prestataire de services informatiques évalue les besoins en conseil fait partie du contexte – les chiffres individuels n'en restent pas moins révélateurs.

Deux résultats se contredisent. 57 % des personnes interrogées indiquent que l'IA est intégrée à leurs processus clés ou largement déployée. Dans le même temps, seuls 32 % ont atteint au moins l'un de leurs deux principaux objectifs en matière d'IA.

L'IA a donc depuis longtemps fait son entrée dans les entreprises – mais elle ne tient pas ses promesses. Cette constatation est corroborée par l'auto-évaluation des entreprises : 79 % d'entre elles estiment que le rythme de développement de l'IA va dépasser celui de leur personnel, de leur gouvernance et de leur modèle opérationnel.

La minorité est plus intéressante que la majorité. Kyndryl identifie un groupe représentant 9 % des entreprises, que le rapport qualifie de „ Pacesetters “. Ces entreprises ont pris trois mesures : elles ont redéfini les rôles liés à l’IA, ont effectivement mis en œuvre la gestion du changement et ont préparé leur personnel à travailler avec l’IA. Selon le rapport, ce groupe a 1,5 fois plus de chances d’enregistrer une croissance de son chiffre d’affaires tirée par l’IA et 1,6 fois plus de chances d’obtenir de meilleurs résultats en matière d’innovation.

Mark Paulek, directeur des ressources humaines chez Kyndryl, résume ainsi les conclusions de l'étude : „ Les leaders qui prennent de l'avance alignent les compétences, les rôles et les processus décisionnels sur la manière dont le travail évolue réellement. “ Ce sont donc ceux qui adaptent les compétences, les rôles et les processus décisionnels à l'évolution réelle du travail qui sont en tête.

Cette étude évalue l'organisation, et non la technologie. C'est précisément là que réside son intérêt : la différence entre ces 9 % et les autres ne réside pas dans le modèle, mais dans la préparation à l'évolution du travail.

Quels sont les défis liés à la mise à l'échelle des flux de travail d'IA ?

Dans le traitement des documents, ces ruptures peuvent être identifiées avec précision. Elles apparaissent presque toujours dans le même ordre, et sont au nombre de quatre :

• L'ensemble de données filtré : Le modèle a été entraîné à partir de 200 factures d'un même modèle. Pour les bons de livraison, cet ensemble de données n'existe pas, et personne n'a consigné la manière dont les données d'entraînement ont été générées.
• Le seuil implicite : Dans le cadre du projet pilote, quelqu'un a fixé un seuil de confiance à partir duquel une pièce comptable est validée sans vérification. Ce seuil ne figure dans aucun document, mais uniquement dans l'esprit du chef de projet.
• Le processus de contrôle au fil du temps : Le service spécialisé s'est habitué à une interface conçue pour un type de document particulier. Chaque nouveau type de document s'accompagne de son propre masque.
• L'absence de référence : Le premier cas d'application est considéré comme une réussite, mais aucun indicateur ne peut être transposé au second.

Le quatrième maillon est le plus coûteux, car il rend les trois autres invisibles. Sans critère de mesure commun, il est impossible de déterminer si le nouveau processus fonctionne mieux que l'ancien – et donc de savoir si la transition en valait la peine.

Ce qui doit évoluer en parallèle lorsque vous mettez en œuvre l'IA

Il s'agit là d'un malentendu courant. Le terme « évolutivité » évoque l'infrastructure, les serveurs et le débit. Dans le domaine du traitement de documents, en revanche, il s'agit avant tout d'une question de mesurabilité. Trois indicateurs doivent être définis dès la première semaine, car ce sont les seuls qui permettent de comparer les différents cas d'utilisation :

• Durée moyenne de traitement par opération : Combien de temps faut-il pour qu'un justificatif soit enregistré depuis son arrivée ? Ce chiffre est également compris par la direction, il permet de comparer le processus manuel et s'applique de la même manière à tous les types de documents.
• Taux de traitement en arrière-plan: La proportion de dossiers traités jusqu'à leur conclusion sans intervention. Ce chiffre permet de déterminer si le deuxième cas d'utilisation a rattrapé le premier.
• Taux d'erreur dans les dossiers traités à l'aveugle : Combien de ces opérations traitées automatiquement étaient erronées ? Sans cette vérification croisée, le taux de traitement en arrière-plan n'a aucune valeur.

Ce dernier point est souvent négligé, et c'est pourtant le plus dangereux. Il est possible à tout moment de faire grimper le taux de traitement « à l'aveugle » en abaissant les seuils de contrôle : le taux augmente, mais les erreurs ne font que se déplacer vers les dernières étapes du processus. Ce n'est qu'associé au taux d'erreur qu'il devient un indicateur fiable.

Les valeurs de confiance et les seuils se situent à un niveau inférieur. Ce ne sont pas des indicateurs, mais des paramètres de réglage. Une valeur de confiance par champ indique le degré de certitude du modèle concernant une valeur extraite donnée. La valeur seuil détermine à partir de quel seuil cette valeur est acceptée sans vérification humaine. C’est sur ces paramètres que l’on agit lorsque le taux d’erreur est trop élevé ou que le taux de traitement en arrière-plan est trop faible.

Deux éléments doivent être consignés par écrit, sinon ils resteront dans la tête du chef de projet. Le seuil varie d'un champ à l'autre : une erreur de montant n'a pas les mêmes conséquences qu'une erreur de numéro de client. Il faut également noter quelle valeur était en vigueur à quel moment. Sans cette note, il ne sera plus possible par la suite de comprendre pourquoi un taux a augmenté.

L'individu reste ainsi en permanence impliqué dans ce processus. L'homme dans la boucle Ce n'est pas une étape intermédiaire vers l'automatisation complète, mais le mécanisme qui permet justement de calibrer les seuils. Quiconque saisit correctement les cas de test génère par la même occasion les données d’apprentissage pour le type de document suivant. C’est précisément ce qui distingue une solution en cours de développement d’une solution aboutie : les corrections apportées par le service métier sont réintégrées dans le modèle, au lieu de se perdre dans un système de tickets.

À quoi reconnaît-on une plateforme capable de s'adapter à des volumes importants de documents ?

La question ne se pose que rarement en termes de débit, car presque toutes les plateformes traitent suffisamment de pages par heure. Les différences résident ailleurs, et trois critères distinguent une plateforme d'une solution ponctuelle :

• Réutilisabilité des modèles : Un modèle déjà entraîné peut-il servir de point de départ pour un type de document similaire, ou chaque projet commence-t-il avec un ensemble de données vierge ?
• Interface d'examen uniforme : Le service spécialisé utilise-t-il le même masque pour tous les types de documents, ou une nouvelle application voit-elle le jour à chaque nouveau cas d'utilisation ?
• Journalisation de bout en bout : Est-il possible de savoir quelles valeurs ont été acceptées automatiquement et lesquelles ont été corrigées manuellement ? Dans les secteurs réglementés, c'est de toute façon obligatoire, et cela constitue la base de données de toute amélioration.

Ces critères s'appliquent quel que soit le fournisseur. C'est la raison pour laquelle AXA met en place une plateforme indépendante des éditeurs plutôt qu'une nouvelle solution spécifique : une couche centrale sur laquelle le traitement des e-mails, la gestion des sinistres et la gestion des connaissances s'appuient sur les mêmes modules.

Comment mettre en place l'IA progressivement, sans s'engager définitivement ?

L'approche pragmatique commence modestement, mais pas au hasard. Le premier cas d'utilisation doit présenter trois caractéristiques :

• Un volume suffisant : Ce n'est qu'à partir d'une certaine quantité que la mesure devient significative.
• Une distinction claire entre le bien et le mal : C'est seulement ainsi que l'on peut détecter les erreurs.
• Un processus voisin : Le transfert vers le type de document suivant doit être réaliste.

La facture fournisseur répond généralement à ces critères : elle arrive en grand nombre, ses champs sont clairs et le bon de livraison se trouve juste à côté.

Ensuite, c'est l'ordre des étapes qui compte. Il faut d'abord mesurer ce que coûte aujourd'hui le processus manuel : le temps de traitement par opération et le taux d'erreur dans les cas que personne ne vérifie. Puis automatiser, et enfin recueillir à nouveau ces deux mêmes chiffres. Sans cette valeur de référence, il sera impossible par la suite de démontrer si la traitement automatisé des documents a amélioré le processus ou se trompe simplement plus vite – et sans cette preuve, le deuxième cas d'utilisation n'obtient pas de budget.

Conclusion

Mettre en œuvre l'IA ne signifie pas simplement mettre un modèle en service. Cela signifie définir les indicateurs de performance sur lesquels le prochain cas d'utilisation devra faire ses preuves.

Les chiffres de Kyndryl mettent en évidence le problème : l'IA est déjà intégrée dans les processus clés de 57 % des personnes interrogées, mais seules 32 % d'entre elles atteignent leurs principaux objectifs. Les 9 % qui progressent ne se distinguent pas par une technologie plus performante, mais par le fait qu’ils ont également repensé les rôles et les processus.

Ce n'est pas le chiffre qui est transposable, mais le mécanisme. Si l’on compare dès le départ le temps de traitement par opération, le taux de traitement en arrière-plan et le taux d’erreur, il n’est pas nécessaire de réinventer le critère de comparaison pour le deuxième type de document. Les valeurs de confiance et les seuils constituent ici les paramètres à ajuster, et non le résultat.

Si vous souhaitez passer à l'étape suivante, ne commencez pas par choisir un modèle. Commencez par évaluer le temps que prend actuellement le traitement d'un document et la fréquence à laquelle des éléments sont omis. Ces deux chiffres détermineront par la suite si un projet pilote débouchera sur la création d'une plateforme.