Automatisation par l'IA des dossiers de sinistre, des tickets et des dossiers KYC sur vos propres serveurs : ce qu'un directeur des opérations doit demander à un prestataire avant de signer

Avant de signer avec un prestataire qui propose d'automatiser par l'IA le traitement de vos dossiers de sinistre, de vos tickets de support ou de vos dossiers KYC sur vos propres serveurs, demandez-lui comment son système s'intégrera au travail que fait aujourd'hui votre back-office. Les bonnes réponses s'accompagnent de chiffres tirés d'un échantillon de vos propres dossiers, par exemple le nombre de dossiers qui devront encore être vérifiés par une personne et ce que coûtera chaque mois le fonctionnement du système. Si un prestataire avance des chiffres avant d'avoir vu vos dossiers, demandez-lui sur quels documents ils ont été mesurés.

Lesquels de nos dossiers le prestataire doit-il voir en premier ?

Commencez par demander quels dossiers le prestataire veut voir. Un prestataire qui a déjà fait ce travail demande en général un mois de dossiers tels que vous les recevez réellement, y compris les scans et les photos prises au téléphone, les fils d'e-mails comportant plusieurs pièces jointes, les formulaires qui reviennent à moitié remplis et les cas que vos équipes font remonter à un superviseur. Il demande aussi quels champs comptent pour vous, comme la date du sinistre sur une déclaration ou la date d'expiration sur une pièce d'identité, et ce qui se passe aujourd'hui quand l'un d'eux est mal lu.

Avant la première réunion, extrayez un mois de dossiers de votre propre système et triez-les selon le temps que chacun a demandé à votre équipe, car c'est sur les dossiers les plus lents qu'il faut tester un prestataire. Comptez combien il y en a de chaque type, et notez ceux qu'un superviseur a dû trancher.

Envoyez à chaque prestataire de votre liste restreinte une description écrite de ces dossiers, avec les décomptes. Les dossiers réels ne sont confiés qu'au prestataire que vous retenez pour un diagnostic payant, un premier contrat court dans le cadre duquel il teste son système sur vos propres serveurs avant que vous signiez le contrat principal. La plupart des chiffres ci-dessous proviennent de ce diagnostic.

Que devient un dossier que le système n'arrive pas à lire ?

Tout back-office a des dossiers sur lesquels le système échouera, comme une photo prise de biais ou un relevé bancaire dans une nouvelle mise en page. Chacun d'eux doit finir entre les mains d'une personne qui peut trancher.

Choisissez trois de vos pires dossiers pour le diagnostic et demandez au prestataire d'expliquer, étape par étape, ce qui arrive à chacun d'eux, de son arrivée jusqu'à la personne qui tranche. Notez toute étape que le prestataire ne sait pas décrire, et revenez-y avant de signer.

Dans une bonne réponse, le dossier va dans une file de revue, une liste de dossiers qu'une personne nommément désignée dans votre équipe traite un par un. Cette personne voit la page avec le champ douteux mis en évidence, et rien n'entre dans votre système de gestion des sinistres ou votre système KYC tant qu'elle n'a pas tranché.

Le prestataire doit aussi expliquer comment le système distingue un dossier qu'il n'arrive pas à lire d'un dossier qu'il a mal lu. Le second cas est plus difficile à repérer, car une date ou un montant erroné ressemble à n'importe quelle autre valeur et passe si rien ne le vérifie.

Combien d'heures de travail faudra-t-il pour vérifier les réponses du système ?

Prenez cinquante dossiers de votre échantillon et chronométrez le temps que votre équipe passe aujourd'hui sur chacun. Pendant le diagnostic, demandez au prestataire quelle part de ce temps la revue prendra encore sur ces mêmes cinquante dossiers. La différence, c'est le temps que le système fait gagner, hors coûts de fonctionnement. Si la différence est faible, mettez-la en balance avec le temps dont vos équipes auront besoin pour apprendre un nouvel outil.

Le système enverra une partie des dossiers en revue, et c'est cette part qui détermine combien de personnes il vous faut. Le prestataire doit l'estimer avant que vous signiez le contrat principal, pour les premières semaines et pour quelques mois plus tard, une fois les erreurs les plus fréquentes corrigées. Sans ces chiffres, vous ne pouvez pas planifier la charge de travail de votre équipe après le lancement.

La revue doit être faite par les personnes qui traitent ces dossiers aujourd'hui, car elles savent à quoi ressemble une réponse correcte. Le prestataire doit vous montrer l'écran qu'elles utiliseront, avec la page et le champ mis en évidence côte à côte, et dire combien de temps prend une revue en moyenne.

Comment savoir si le système est aussi précis que nos équipes ?

Demandez à deux de vos collaborateurs d'écrire les bonnes réponses pour cinquante dossiers de votre échantillon, sans se concerter. Là où ils ne sont pas d'accord, votre équipe n'a pas encore de réponse commune, et le système ne peut pas être noté sur ces dossiers. Convenez de la manière dont ces cas sont tranchés avant le début des tests.

Les prestataires donnent généralement l'exactitude sous la forme d'un pourcentage unique pour l'ensemble du système. Un score utile est donné pour chaque champ, comme une date ou un montant, et pour chaque type de document. Les scores doivent venir de votre jeu de test : des dossiers de votre échantillon, avec les bonnes réponses écrites par vos propres équipes, que le prestataire n'a pas utilisés pendant qu'il ajustait le système. Vos équipes se trompent aussi, alors mesurez-les sur les mêmes dossiers pour voir à quoi le système est comparé.

Une bonne réponse fixe le seuil de réussite, le score minimal que le système doit atteindre, avant que le prix soit convenu. Elle précise quels champs le système peut remplir seul une fois ce score atteint, et quels champs vont toujours à une personne. Fixez le seuil de réussite d'après ce que vous coûte une erreur, comme un sinistre payé deux fois ou un compte ouvert au nom de la mauvaise personne, et communiquez-le par écrit au prestataire.

L'article sur les pilotes d'IA qui ne sont jamais passés en production, dont le lien figure juste au-dessus, explique comment constituer le jeu de test.

Que se passe-t-il lors de notre journée la plus chargée ?

Certains jours apportent bien plus de dossiers que d'autres, comme la fin de mois ou le matin qui suit une tempête. Un système qui suit le rythme un jour ordinaire peut prendre du retard ce jour-là.

Retrouvez dans vos propres historiques la journée la plus chargée de l'année écoulée, avec le nombre de dossiers, et demandez au prestataire d'expliquer comment son système y aurait fait face. Les serveurs sont les vôtres : demandez donc aussi ce qu'impliquerait un ajout de capacité un tel jour, et combien de temps cela prendrait.

La réponse doit indiquer combien de dossiers par heure le système peut absorber sur les serveurs que vous mettrez à sa disposition, et qui reçoit un appel quand des dossiers attendent depuis plus d'une heure. Les dossiers doivent attendre dans l'ordre, les types urgents en premier, et quelqu'un de votre côté doit pouvoir faire repasser un type de document en traitement manuel. Aucun dossier n'est écarté ni transmis sans vérification pour résorber le retard plus vite.

Combien coûtera chaque mois le fonctionnement du système ?

Les coûts de fonctionnement s'ajoutent au prix du développement et durent aussi longtemps que le système tourne. Sur vos propres serveurs, ils comportent au moins quatre postes :

• les serveurs qui font tourner le modèle
• les personnes qui surveillent le système et traitent ses alertes
• le temps que vos équipes consacrent à la revue
• le travail de mise à jour du système quand les modèles et les documents changent

Obtenez de chaque prestataire une estimation mensuelle, avec ses hypothèses par écrit : dossiers par mois, pages par dossier, nombre de dossiers de chaque type et serveurs prévus. Comparez ensuite ces hypothèses avec votre volume réel. Si un prestataire donne un coût de fonctionnement sans hypothèses, demandez-lui de les mettre par écrit avant de comparer son chiffre à ceux des autres prestataires.

Le contrat doit énumérer ce que couvrent, après le lancement, les frais mensuels de support du prestataire, par exemple si l'adaptation du système à un nouveau gabarit de document est incluse ou facturée à part.

Cet article ne donne pas de prix, car le coût dépend de votre volume et de vos serveurs. Chaque prestataire doit le calculer à partir de vos propres chiffres.

Qui s'en aperçoit quand nos documents ou le modèle changent ?

Après le lancement, vos documents vont changer, par exemple quand une banque partenaire modifie la présentation de ses relevés ou qu'une nouvelle gamme de produits apporte un nouveau formulaire. Le modèle peut changer lui aussi, quand une version plus récente sort ou que le logiciel qui le fait tourner sur vos serveurs cesse de prendre en charge l'ancienne.

Quand le modèle change, le système doit être noté de nouveau sur votre jeu de test, champ par champ, avant la bascule, et vous devez pouvoir revenir en arrière. Convenez à l'avance de qui paie chacun de ces tests.

Si, à partir de mardi, tous les relevés d'une banque partent en revue, ou si un champ est mal lu pendant une semaine, les écrans de suivi des serveurs n'afficheront toujours aucune erreur. Pour s'en apercevoir, quelqu'un de votre côté doit vérifier chaque semaine quelle part de chaque type de document part en revue, et le prestataire doit dire ce qu'il fait quand cette part change.

Que possédons-nous à la fin, et qui exploite le système après le départ du prestataire ?

À la fin du projet, vous devez disposer de tout ce qu'il faut pour exploiter et modifier le système sans le prestataire. Cela comprend le code, les prompts (les instructions écrites que suit le modèle), le jeu de test avec ses bonnes réponses, les scripts qui notent le système et la documentation. Inscrivez cette liste dans le contrat, ainsi que les composants réutilisables du prestataire, chacun désigné nommément, et ce que vous avez le droit d'en faire.

Demandez ensuite qui exploite le système de votre côté. Le prestataire doit décrire le rôle et ce que cette personne doit savoir, et la formation doit être terminée avant le lancement. Si la réponse est « nous l'exploiterons pour vous », demandez ce qui se passe à la fin du contrat et ce que coûte la passation.

Le règlement européen sur l'IA (AI Act) s'applique-t-il à notre système ?

L'article 4 du règlement européen sur l'IA (AI Act) s'applique depuis le 2 février 2025. Dans sa rédaction actuelle, issue du règlement (UE) 2026/1744 de juillet 2026, il impose aux fournisseurs et aux déployeurs de systèmes d'IA de prendre des mesures pour favoriser la maîtrise de l'IA par leur personnel et par les autres personnes qui s'occupent du fonctionnement et de l'utilisation des systèmes pour leur compte. Il n'exige de personne un niveau particulier de maîtrise de l'IA.

Le règlement classe certains usages à haut risque, parmi lesquels l'évaluation de la solvabilité des personnes physiques, sauf pour la détection de fraudes financières, ainsi que l'évaluation des risques et la tarification en matière d'assurance-vie et d'assurance maladie. Pour ces usages, l'article 26 ajoute des obligations à la charge de l'entreprise qui déploie le système, et, en vertu de la modification de 2026, elles s'appliquent à partir du 2 décembre 2027. Le contrôle humain est alors confié à des personnes qui disposent « des compétences, de la formation et de l'autorité nécessaires », et l'entreprise surveille le fonctionnement du système. Les journaux que le système génère sont conservés pendant au moins six mois lorsqu'ils sont sous le contrôle de l'entreprise, sauf si un autre texte en dispose autrement.

Les banques, les assureurs et les autres établissements financiers soumis à la législation de l'Union sur les services financiers remplissent l'obligation de surveillance en appliquant leurs règles existantes de gouvernance interne, et conservent les journaux avec la documentation que ces règles exigent déjà.

C'est à vos juristes de dire si votre système relève de ces règles, et cet article ne constitue pas un conseil juridique. Former vos équipes et désigner la personne qui exploite le système de votre côté sont utiles dans tous les cas.

Quelles réponses laissent penser qu'un prestataire n'a encore jamais fait ce travail ?

• Le prestataire donne un chiffre d'exactitude sans avoir vu un seul de vos dossiers
• Le prestataire affirme que le modèle « gère bien les cas limites » et ne sait pas dire où va un dossier illisible
• Le plan ne prévoit pas de file de revue, ou laisse la revue à vos équipes sans estimation du nombre d'heures
• Personne chez le prestataire ne sait dire ce qui se passe quand il arrive plus de dossiers que le système ne peut en traiter
• Le coût de fonctionnement mensuel est donné sans les volumes ni les serveurs sur lesquels il repose
• La formation de vos équipes commence après le lancement, ou n'a pas lieu du tout

Où se situe amBrain ?

Le seul projet de modèle de langage qu'amBrain décrit publiquement est le suivant : « Nous avons mené une intégration de LLM jusqu'en production dans le périmètre FinTech d'un client : extraction et normalisation d'avis non structurés de courtiers et de places de marché — opérations sur titres, changements d'instruments et de marges — en enregistrements structurés consommés par le système de trading. »

Cet article n'est pas une étude de cas, et le client n'est pas nommé. Il ne dit pas qu'amBrain a construit un système pour des dossiers de sinistre, des tickets de support ou des dossiers KYC. L'endroit où tournait le modèle dans ce projet n'est pas divulgué, pas plus que celles des pratiques ci-dessus qui y ont été appliquées. Il ne donne ni prix ni délais d'amBrain.

amBrain développe des logiciels depuis 2019. Elle décrit en une ligne sa façon de travailler avec ses clients : « Trois formats : livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe. » Sur la propriété, sa formule est : « Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables. » Demandez à amBrain la liste nominative de ces composants, comme vous le feriez auprès de n'importe quelle autre société.

Si amBrain figure sur votre liste restreinte, envoyez-lui les mêmes questions écrites qu'aux autres prestataires.

Questions fréquentes

• Notre pilote fonctionne déjà. Ces questions restent-elles valables ? Oui. Un pilote montre en général que le système sait lire une partie de vos dossiers, et dit peu de chose des autres questions ci-dessus. L'article sur les projets d'IA clés en main, dont le lien figure en haut de la page, explique comment payer le travail qui transforme un pilote en un système que votre back-office peut exploiter
• Faire tourner le système sur nos propres serveurs signifie-t-il qu'aucune donnée ne part vers un fournisseur de modèles externe ? Seulement si chaque étape y tourne. Demandez au prestataire d'indiquer par écrit quel modèle tourne où, et si une étape fait appel à un service extérieur, comme un modèle hébergé ou un service de reconnaissance de texte
• Qui, de notre côté, doit participer à ces réunions ? La personne qui dirige le back-office aujourd'hui, et quelqu'un de votre équipe informatique qui donnera ses accès au prestataire et sait ce que vos serveurs peuvent supporter