Applications métier assistées par IA
Nous ne considérons pas l'IA comme un produit à part, mais comme un composant qui s'intègre dans le travail existant de l'organisation. Un modèle ne devient vraiment utile qu'une fois relié aux propres données et règles de processus de l'organisation.
Quand on parle d'IA, la discussion porte souvent sur le choix du modèle. Côté entreprise, ce qui détermine réellement le résultat n'est généralement pas ce choix, mais les données auxquelles le système accède, les règles qui le contraignent, et qui valide la réponse donnée. Rendre une tâche assistée par IA consacre l'essentiel de l'effort à répondre à ces trois questions.
C'est pourquoi nous commençons le développement par un seul processus. Par exemple l'analyse des factures entrantes, l'extraction d'informations dans un ensemble de contrats, la classification de relevés de terrain, ou la possibilité pour l'utilisateur d'interroger ses propres données en langage naturel. En gardant un périmètre étroit, on peut mesurer si le résultat est correct et corriger le système avant un déploiement plus large.
L'application elle-même reste le travail de logiciel d'entreprise que nous connaissons : modèle de données, autorisation, piste d'audit, intégration avec les systèmes existants. L'IA s'insère dans cette structure comme un composant à la responsabilité clairement définie. Ce que rencontre l'utilisateur n'est pas un nouvel écran, mais une version du système qu'il utilise déjà, demandant moins de travail manuel.
Sommes-nous le bon interlocuteur ?
Pour les tâches dont la règle est claire, l'IA est une couche superflue. Si une règle peut s'écrire, l'écrire reste à la fois moins coûteux et vérifiable. Cette technologie est utile là où la règle ne peut pas s'écrire, mais où des exemples existent.
Oui, discutons-en
- Il existe une tâche manuelle, répétitive, dont le résultat est vérifiable
- La décision repose sur un document, du texte libre ou des données non structurées
- L'organisation dispose de suffisamment d'exemples montrant à quoi ressemble la bonne réponse
Non, quelqu'un d'autre le fera mieux
- La tâche est déjà définie par des règles — un logiciel classique est moins cher et plus précis
- Il s'agit d'une décision où un résultat erroné entraînerait une conséquence irréversible
- Les données de l'organisation sont dispersées ; les rassembler constituerait déjà un projet à part entière
Ce que nous faisons
- Évaluation du processus — déterminer quelle tâche convient à cette technologie
- Infrastructure de questions-réponses sur les propres documents et registres de l'organisation
- Lecture de documents, extraction de champs et classification
- Interfaces de reporting et d'interrogation de données en langage naturel
- Aide à la décision et génération de recommandations liées au flux de travail
- Intégration aux systèmes d'entreprise et sources de données existants
- Choix du modèle ; évaluation du coût, de la rapidité et de la confidentialité des données
- Décision et mise en place d'un fonctionnement sur site ou dans le cloud
- Mesure de la précision des résultats, validation humaine et piste d'audit
- Interfaces de capacités que les clients IA peuvent appeler
Comment nous procédons
Choix du processus
Toutes les tâches d'une organisation ne se prêtent pas à cette technologie. Nous choisissons un processus manuel, répétitif, dont le résultat est vérifiable ; nous bâtissons la première application dessus.
Extraction des données et des règles
Nous rassemblons les documents, registres et définitions internes sur lesquels repose le processus. Là où les données sont dispersées ou les définitions jamais écrites, le vrai travail commence ici.
Critère de précision
Nous définissons la bonne réponse à partir des propres exemples de l'organisation. Sans critère établi, la qualité d'un résultat reste affaire d'opinion.
Développement de l'application
Nous intégrons le modèle dans l'application d'entreprise. L'autorisation, la journalisation et le renvoi vers un humain en cas d'incertitude sont mis en place à cette étape.
Mise en service et supervision
En phase initiale, nous faisons passer les résultats par une validation humaine. À mesure que les résultats de mesure s'accumulent, nous déterminons quelles étapes peuvent fonctionner sans validation.
Nos choix techniques
- Le composant d'IA est positionné de façon à ne jamais sortir des règles de l'application. Les limites d'autorisation, les données accessibles et l'étape de validation restent dans la propre couche du système ; le texte produit par le modèle ne peut pas modifier ces règles. Sinon, qui peut accéder à quoi devient aussi incertain que l'exactitude du résultat.
- Chaque résultat est enregistré. On conserve la question posée, les données utilisées pour y répondre, la version en cours et si l'utilisateur a validé le résultat. Sans ce registre, quand le système produit un résultat erroné, il devient impossible de revenir en arrière et d'en trouver la cause.
- La précision se mesure sur un jeu d'exemples, pas au jugé. Un ensemble de validation constitué à partir des propres documents de l'organisation permet de répéter le même test à chaque changement de version. C'est le seul moyen de voir ce qui se dégrade quand le modèle ou la consigne change.
- L'endroit où les données sont traitées n'est pas une préférence technique, mais une décision de l'organisation. Pour les besoins à forte exigence de confidentialité, des modèles fonctionnant sur site sont envisagés ; sinon, des services cloud. Le choix se fait entre coût, rapidité et confidentialité, et il est consigné avec sa justification.
- Le système est conçu pour renvoyer à un humain les cas dont il n'est pas certain. Une structure qui met en file les cas douteux est plus utile qu'une structure qui tranche tout seule ; on peut voir où les erreurs s'accumulent, et la correction s'applique précisément là.