Créer un SaaS IA : choisir un usage, tester la qualité

Partir d’une tâche limitée

« Ajouter un assistant » ne suffit pas à définir une fonctionnalité. Décrivez ce qu’il reçoit, ce qu’il produit et la personne qui utilise le résultat. Résumer des notes internes, proposer une réponse client et déclencher une action métier n’ont pas les mêmes conséquences en cas d’erreur.

Choisissez un premier cas où le résultat peut être vérifié. La revue humaine peut faire partie du produit, à condition d’être claire et praticable. Ne cachez pas une validation nécessaire derrière une promesse d’autonomie.

Définir les frontières des données

Identifiez les sources autorisées, les droits par organisation et les données qui ne doivent pas être transmises à un fournisseur externe. Une recherche documentaire doit appliquer les permissions avant de fournir les éléments au modèle. Une réponse plausible ne justifie jamais de contourner l’isolation des comptes.

Les documents récupérés sont des données non fiables du point de vue des instructions. Leur contenu peut contenir des demandes de détourner le système. Délimitez ce que le modèle peut lire et ce qu’il peut faire ; contrôlez les actions dans le code serveur plutôt que de vous fier uniquement au prompt.

Construire un jeu d’évaluation

Rassemblez des exemples représentatifs : demandes fréquentes, ambiguïtés, informations manquantes et cas difficiles. Définissez les critères de jugement avant de comparer des variantes. Pour une extraction, vérifiez les champs ; pour une réponse documentaire, vérifiez l’appui sur les sources ; pour une action, vérifiez les paramètres et les permissions.

Conservez les résultats de manière à repérer les régressions. Un changement de modèle, de prompt ou de récupération peut améliorer certaines réponses et en dégrader d’autres. La démonstration la plus réussie ne doit pas devenir le seul critère de mise en production.

Prévoir les refus et les erreurs

Un produit fiable doit expliquer ce qui s’est passé. Les messages d’erreur doivent éviter de faire croire qu’une action a été effectuée lorsqu’elle ne l’a pas été. Les opérations répétées nécessitent également une stratégie contre les doublons.

Concevoir le coût et la latence

Modélisez les appels par tâche, le volume des entrées, les reprises et la fréquence d’usage. Limitez les traitements inutiles et choisissez les sources pertinentes. Une optimisation du coût qui détériore la qualité sur les tâches critiques peut être un mauvais compromis.

L’interface doit gérer l’attente : état de progression, annulation lorsque possible et récupération après interruption. Ne bloquez pas une tâche simple derrière un traitement long si une partie du résultat peut être préparée de manière déterministe.

Exemple pédagogique

Pour un copilote de suivi de projet, commencez par proposer une synthèse de notes avec liens vers les passages utilisés. L’utilisateur vérifie puis publie. L’envoi automatique d’instructions à des équipes représente un autre niveau de risque et doit être cadré séparément, avec contrôle des destinataires et du contenu.

Construire un jeu d’évaluation représentatif

Pour un assistant fictif de classement de demandes, réunissez des exemples simples, ambigus, incomplets et hors sujet. Décrivez la sortie attendue et les cas où une abstention est préférable à une réponse. Séparez les exemples utilisés pour régler le système de ceux réservés à la vérification finale. Sinon, une amélioration peut simplement refléter une adaptation aux questions déjà vues.

Évaluez plusieurs dimensions : exactitude de la catégorie, respect du format, justification utile, délai et coût d’une tâche terminée. Un résultat syntaxiquement correct peut rester faux. Inversement, demander une précision peut être le meilleur comportement lorsque les informations manquent. Faites relire les erreurs par une personne qui connaît le processus métier ; un score moyen ne suffit pas à déterminer leur gravité.

Définir la frontière entre suggestion et action

Un brouillon de réponse peut être relu avant envoi. Une modification de dossier ou une action financière exige d’autres contrôles. Listez précisément ce que le système peut lire, proposer et exécuter. Les permissions doivent être vérifiées par le logiciel au moment de l’accès, indépendamment de ce que le modèle affirme être autorisé à faire. Un document importé ne doit pas pouvoir donner de nouvelles instructions au système.

Mesurer le coût d’un résultat accepté

Le prix d’un appel ne représente pas le coût total du service. Comptez la recherche documentaire, les reprises, le traitement des fichiers et le temps de contrôle nécessaire. Pour un pilote, relevez le nombre de tâches acceptées sans correction et celles qui demandent une reprise. Comparez ensuite ce coût au processus actuel avec les mêmes limites et le même niveau de qualité.

Prévoyez un jeu de non-régression avant de changer de modèle, de consigne ou de source documentaire. Un changement favorable à une catégorie peut dégrader une autre. Gardez la possibilité de revenir à la configuration précédente et d’expliquer quelle version a produit une sortie, sans conserver inutilement de données sensibles.

Atelier : préparer le changement de modèle sans régression silencieuse

Un produit IA continue d’évoluer après son premier lancement : modèle, instructions, documents de référence et outils peuvent changer. Préparez donc une procédure de comparaison avant la prochaine modification. L’exercice suivant porte sur un assistant fictif qui propose une réponse à une demande de support. Il ne suppose aucun taux de réussite particulier et ne remplace pas les contrôles propres à un domaine sensible.

Conservez un ensemble de situations représentatives avec les critères de réponse attendus. Pour chaque cas, indiquez les informations disponibles, ce que l’assistant peut affirmer, ce qu’il doit demander et ce qu’il doit refuser d’exécuter. Une réponse de référence unique ne suffit pas toujours : plusieurs formulations peuvent être acceptables, mais aucune ne doit inventer un remboursement déjà effectué.

Exécutez les mêmes situations avec l’ancienne et la nouvelle configuration. Conservez la version du modèle, des instructions et des documents utilisés. Si le comportement varie entre répétitions, relevez cette variabilité au lieu de sélectionner seulement la meilleure réponse. Faites examiner les désaccords importants par une personne qui connaît le métier concerné.

Définissez les défauts bloquants séparément des préférences de style. Une formulation moins élégante et une divulgation non autorisée ne se compensent pas dans une moyenne. Le passage en production dépend de seuils choisis pour le risque réel du produit, et non d’un score universel. Documentez qui accepte les écarts restants.

Préparez enfin le retour arrière. L’équipe doit savoir quelle configuration restaurer, comment arrêter une action automatisée et comment identifier les tâches touchées pendant la période concernée. Restaurer un modèle n’annule pas une action déjà effectuée dans un système externe : les autorisations et confirmations restent donc essentielles en amont.

Le livrable est un dossier de changement : cas rejoués, différences observées, décisions, version déployée et procédure de retrait. Cette discipline facilite les améliorations tout en évitant qu’un changement apparemment mineur des instructions modifie discrètement la promesse du produit.

Questions fréquentes

Faut-il un agent autonome ?

Seulement si la tâche exige réellement une suite de décisions et d’actions. Un workflow déterministe autour d’un appel de modèle peut être plus simple à tester et à superviser.

Le RAG supprime-t-il les erreurs ?

Non. La récupération peut améliorer l’accès à des informations utiles, mais les sources, permissions, extraits et réponses doivent être évalués. Une citation visible n’est pas une garantie que la conclusion est correcte.

Que livrer avant le développement complet ?

Un cas d’usage limité, un jeu d’exemples, des critères de qualité, un schéma des données et une description des actions autorisées. Ce dossier permet de discuter du produit au-delà de la démonstration.

Les exemples sont pédagogiques et ne décrivent pas des résultats clients. Contenu préparé avec assistance IA ; voir notre politique éditoriale. Notre méthode ↗