Ajouter l'IA à un logiciel métier : là où elle aide

Nous intégrons des fonctions d'IA dans des logiciels métier, et une bonne part de nos échanges à ce sujet se termine par la recommandation de ne pas le faire. Ce n'est pas de la modestie. Un modèle est un bon outil pour un type de travail précis, et un outil coûteux et imprévisible pour tout le reste. Savoir lequel est lequel avant de construire quoi que ce soit, c'est l'essentiel de la valeur.

Le scénario qui tourne mal est connu. Une fonction est choisie parce qu'elle se présente bien en démo, le plus souvent une fenêtre de discussion, et on l'ajoute là où elle se voit plutôt que là où se trouve le travail manuel. Personne ne définit à quoi ressemble une bonne réponse, donc personne ne peut dire si elle fonctionne. Six mois plus tard, elle est toujours là et personne ne s'en sert.

Quatre tâches qu'elle fait bien

Presque toutes les fonctions d'IA qui méritent leur place dans un logiciel métier relèvent de l'une de ces quatre, et chacune remplace une personne qui lit un texte et saisit ce qu'elle y a trouvé.

1. Lire des documentsFactures fournisseurs, bons de commande, relevés bancaires et bons de livraison lus dans des champs structurés. Le modèle lit ; du code ordinaire vérifie ensuite ce qu'il a lu – que les totaux de lignes concordent, que le GSTIN a la bonne forme, que le fournisseur existe. La plupart des erreurs d'extraction sont interceptées par ces contrôles avant que quiconque les voie.
2. Trier ce qui arriveDemandes, tickets et e-mails dirigés vers la bonne file, étiquetés par urgence ou signalés lorsqu'ils nécessitent une personne expérimentée. Une mauvaise supposition ne coûte qu'une réaffectation, et c'est ce qui en fait une bonne première tâche.
3. Retrouver des informations dans vos propres archivesDes réponses tirées de vos documents, procédures et dossiers passés, avec la source citée à côté de la réponse. Sans la citation, c'est une paraphrase assurée que personne ne peut vérifier ; avec elle, c'est une recherche plus rapide.
4. Rédiger pour une personneRéponses, lettres d'accompagnement de devis, descriptions de produits et résumés de longs échanges, préparés pour qu'une personne les corrige et les valide. Le gain est réel quand corriger un brouillon est plus rapide qu'écrire à partir de rien, et seulement dans ce cas.

Là où elle ne doit pas décider

Tout ce qui relève d'un calcul ou d'une règle a sa place dans le code. La paie, la GST, la valorisation des stocks, les intérêts, les remises et l'éligibilité ont une seule bonne réponse qu'un auditeur peut retracer, alors qu'un modèle produit une réponse plausible, généralement juste. « Généralement » n'est pas une norme sur laquelle on peut déposer une déclaration.

• Les calculs fiscaux et réglementaires, même lorsqu'un modèle saurait parfaitement expliquer la règle.
• Les validations ayant une conséquence financière ou juridique, comme les plafonds de crédit, les remboursements et les passages en pertes.
• Tout ce qui exige que la même entrée donne toujours le même résultat.
• Les faits absents des données qu'on lui a fournies. Interrogé sur quelque chose qu'il ne voit pas, un modèle comble le vide avec quelque chose qui sonne juste.

Mesurer avant de livrer

La seule habitude qui distingue les fonctions d'IA qui durent de celles qu'on finit par désactiver est un jeu d'évaluation, constitué avant la fonction et non après les plaintes.

1. Réunir des cas réelsTirés de vos propres documents et messages, y compris les plus délicats – scans médiocres, écriture manuscrite, langues mélangées, le fournisseur dont la mise en page des factures change chaque trimestre.
2. Écrire la bonne réponsePour chaque cas, ce qu'une personne attentive aurait produit. C'est fastidieux, et c'est l'étape qui rend possible tout ce qui suit.
3. Mesurer par champ, pas globalementUn lecteur de factures qui lit bien les totaux et mal les dates a un problème précis et corrigeable. Un taux de précision unique le masque.
4. Fixer un seuilEn dessous d'un niveau de confiance convenu, le cas part vers une personne au lieu de passer. Le seuil est une décision métier, et elle doit vous revenir.
5. Relancer à chaque modificationUn nouveau prompt ou un nouveau modèle devient une comparaison mesurée sur le même jeu, et non un changement que personne n'ose faire.

La validation humaine

Chaque fonction d'IA exige de décider ce qui se passe sans intervention humaine. Pour la plupart des tâches métier, le bon point de départ est de préparer des brouillons à valider et de ne jamais agir sans supervision, puis d'élargir cela seulement dans la mesure où les chiffres mesurés le justifient.

La validation ne fait gagner du temps que si vérifier est plus rapide que faire. Il faut donc afficher la source à côté du résultat – l'image de la facture à côté des champs extraits, le paragraphe cité à côté de la réponse – pour que la personne confirme au lieu de refaire. Un écran de contrôle qui oblige à chercher l'original a discrètement annulé le gain.

Coût, rapidité et données

• La tarification se fait à l'appel, donc la facture suit le volume. Estimez le volume mensuel et la taille de chaque requête avant de construire, pas après la première facture.
• Mettez en cache le travail qui se répète et orientez les cas simples vers des modèles plus petits et moins chers. L'essentiel du volume, ce sont des cas simples.
• Fixez un budget de latence. Une fonction qui prend plusieurs secondes dans un écran chargé ne sera pas utilisée, aussi bonnes que soient ses réponses.
• Décidez quelles données peuvent quitter votre infrastructure et masquez ce qui n'a pas besoin d'être envoyé. Des données personnelles dans un prompt restent des données personnelles au sens de la loi indienne DPDP.
• Vérifiez les conditions du fournisseur sur la conservation et l'entraînement. Les conditions des API entreprise excluent en général l'entraînement sur les données soumises ; quand cela ne suffit pas, un modèle à poids ouverts peut tourner sur vos propres serveurs.

Un premier projet raisonnable

Choisissez une tâche fréquente, peu risquée et facile à vérifier. Lire les factures fournisseurs pour en faire une écriture d'achat validée par une personne est un bon exemple : le volume est réel, une erreur est repérée à la validation, et le temps gagné est facile à mesurer. Constituez le jeu d'évaluation, mettez la fonction en service derrière la validation, et regardez les chiffres au bout d'un mois.

S'ils sont bons, la tâche suivante est plus facile à justifier et plus rapide à construire, car l'habitude de l'évaluation et l'écran de contrôle existent déjà. S'ils ne le sont pas, vous l'avez appris à peu de frais – et parfois ce que l'on apprend, c'est que le problème venait d'un formulaire mal conçu, qui n'avait besoin d'aucun modèle.