Une démonstration se déroule souvent dans des conditions favorables. La personne qui la présente connaît le parcours. Son compte dispose des bons accès. Les données sont prêtes. Si quelque chose manque, elle sait comment poursuivre.
Un utilisateur arrive avec d’autres conditions : un téléphone, un compte récent, une information incomplète ou une attente que le scénario n’avait pas prévue. Passer à l’usage quotidien demande de confronter le produit à ces situations.
L’IA facilite la réalisation d’un prototype. Elle peut aussi aider à préparer et exécuter les vérifications. Le choix de ce qu’il faut vérifier reste lié au produit et aux conséquences d’une erreur.
Commencer avant l’écran qu’on veut montrer
Pour vérifier une fonctionnalité, on peut être tenté d’ouvrir directement la page concernée. Cela laisse de côté ce que l’utilisateur doit réussir auparavant : trouver le point d’entrée, créer son compte, recevoir un message ou retrouver une session.
Un parcours complet commence là où commence l’expérience de la personne. Il se termine lorsque le résultat attendu est réellement obtenu, y compris lorsqu’un service externe intervient.
Il faut aussi regarder ce qui se passe en cas d’interruption. La personne comprend-elle si l’action a abouti ? Peut-elle recommencer sans créer un doublon ? Les informations déjà saisies sont-elles conservées ? Ces questions sont souvent plus utiles qu’une nouvelle démonstration du parcours idéal.
Utiliser les droits du futur utilisateur
Un compte administrateur facilite les essais. Il peut aussi masquer des défauts, parce qu’il contourne les restrictions qui s’appliquent aux autres personnes.
On prépare donc des comptes représentatifs des rôles du produit. Pour chaque action importante, on examine qui doit pouvoir l’accomplir et qui doit en être empêché. Cela concerne la visibilité d’un écran, mais aussi l’accès effectif aux données et aux opérations derrière cet écran.
Le même raisonnement vaut pour l’appareil. Une vérification sur un navigateur de bureau ne suffit pas à établir qu’un parcours mobile fonctionne correctement. Les simulations sont utiles pour couvrir rapidement des configurations ; les usages importants méritent aussi un contrôle dans les conditions réelles prévues.
Dans notre pratique de construction avec l’IA, ces écarts ont conduit à préciser les scénarios demandés aux agents. « Vérifier l’écran » laisse trop de latitude. Décrire le rôle, le point de départ et le résultat attendu rend le contrôle plus utile.
Préparer ce qui se passe quand le produit échoue
La mise en production suppose de pouvoir détecter un problème et agir. Quels événements doivent être observés ? Qui reçoit une alerte ? Comment distinguer un échec isolé d’un incident qui touche plusieurs utilisateurs ?
Le suivi doit rester proportionné et limiter les données collectées. Une trace d’erreur utile n’a pas besoin d’exposer tout le contenu d’un document utilisateur. Il faut savoir ce que l’on conserve, qui peut le consulter et pourquoi.
Il est également nécessaire de préparer les moyens de reprise. Selon le produit, cela peut inclure le retour à une version précédente, la désactivation d’une fonction ou la restauration de données. Ces moyens demandent des vérifications : disposer d’une sauvegarde et savoir restaurer le service sont deux choses différentes.
Ces sujets entrent dans les choix de construction. Les découvrir seulement après le premier incident réduit les options disponibles.
Si le produit utilise lui-même de l’IA
Un logiciel construit avec des agents ne contient pas nécessairement une fonction générative. Quand le produit utilise lui-même un modèle pour répondre ou agir, une autre couche de vérification s’ajoute.
Les tests du logiciel vérifient ses règles et ses intégrations. Les évaluations de la fonction IA examinent la qualité de ses résultats sur des situations représentatives, y compris les erreurs, les demandes ambiguës et les actions qu’elle doit refuser ou faire valider.
Un changement de modèle, de consigne ou de source documentaire peut modifier le comportement. Il faut pouvoir rejouer ces cas, observer les régressions et suivre les résultats en production. Anthropic décrit plusieurs formes d’évaluation des agents, qui combinent contrôles automatiques et appréciation humaine selon la tâche.
L’état final mérite une attention particulière lorsqu’un agent agit. Affirmer qu’un rendez-vous a été créé n’est pas la même chose que constater sa présence, au bon moment et pour la bonne personne. Les coûts, les délais de réponse et les reprises après échec font aussi partie de la qualité du service.
Choisir une première mise en service maîtrisable
Tout vérifier avec la même profondeur avant toute livraison serait irréaliste. On peut limiter le premier périmètre, restreindre les utilisateurs concernés ou conserver une validation humaine sur certaines actions.
Le choix dépend des conséquences d’un défaut et de la possibilité de revenir en arrière. Un outil interne qui prépare un brouillon n’engage pas les mêmes risques qu’une fonction qui modifie des données ou exécute une opération externe.
La mise en service permet ensuite d’enrichir les contrôles à partir des situations rencontrées. Les retours, les erreurs et les difficultés d’usage alimentent les prochaines évolutions.
C’est la continuité entre nos offres Construire des produits et Faire évoluer des produits : préparer l’exploitation pendant la construction, puis entretenir et améliorer le produit à partir de ce qui se passe réellement.