Intégrer l’IA dans un processus métier

Choisir un cas d’usage étroit et observable

Le bon point de départ est une tâche répétée, coûteuse à préparer et facile à contrôler : classer des demandes, extraire des informations, préparer une synthèse ou retrouver une règle dans un corpus documentaire.

Le résultat attendu se décrit avant le choix du modèle. Temps de traitement, taux de reprise humaine, cas refusés et coût par exécution forment une ligne de départ. Sans cette référence, le pilote peut impressionner sans prouver qu’il améliore le processus. Les solutions IA commencent donc par le travail, pas par le fournisseur.

• Une entrée et une sortie clairement définies.
• Des exemples réels représentatifs, y compris les cas difficiles.
• Une personne capable de valider le résultat.
• Une mesure avant le prototype et la même mesure après.

Préparer les données et leur droit d’usage

Le modèle ne corrige pas une source obsolète, contradictoire ou inaccessible. Les documents doivent être identifiés, datés, nettoyés et associés à des règles de visibilité. Une réponse utile cite la source qui permet de la vérifier.

Le traitement des données personnelles, confidentielles ou réglementées se décide avant l’envoi au modèle. Hébergement, conservation, journalisation et exclusion de l’entraînement sont écrits dans l’architecture et dans les contrats, pas supposés.

Décider ce que la machine peut préparer, proposer ou exécuter

Toutes les actions n’ont pas le même risque. Résumer un document, préparer un brouillon et envoyer un message à un client ne demandent pas le même niveau de contrôle.

Une matrice simple distingue lecture, proposition et action. Elle précise les outils accessibles, les limites, les données autorisées et les cas qui imposent un refus. Le logiciel métier porte ensuite ces règles dans les droits, les interfaces et les journaux.

Construire la validation humaine dans le parcours

Écrire « un humain garde la main » ne suffit pas. L’interface doit montrer la proposition, sa source, son niveau d’incertitude et la conséquence de l’action. La validation arrive avant l’envoi ou la modification irréversible.

Les corrections humaines deviennent des cas de test. Elles permettent de suivre les erreurs récurrentes, de modifier les instructions et de décider si le périmètre peut s’élargir. Stellary applique ce principe à des missions d’agents rattachées à des projets et supervisées dans le même système.

Mesurer les coûts et prévoir le changement de modèle

Le coût réel additionne le modèle, la recherche documentaire, le stockage, les outils appelés, l’observation et le temps de validation. Il se mesure par cas d’usage et par résultat accepté, pas seulement par jeton.

Les modèles évoluent vite. Le produit garde donc une couche d’évaluation, des jeux de tests et une interface d’intégration remplaçable. Un changement de fournisseur ne doit ni réécrire le processus ni rendre les résultats incomparables. Pour confronter un cas réel à ces contraintes, le point de départ reste un échange de cadrage.

• Journaliser le modèle, sa version et le coût de chaque exécution.
• Tester les changements sur un jeu de cas stable.
• Prévoir les limites de volume et les alertes de dépense.
• Documenter la procédure de désactivation ou de retour au traitement manuel.