Partir des conséquences possibles

Décrivez les actions autorisées et demandez ce qui se passerait si elles étaient mal exécutées. Une mauvaise synthèse peut tromper un commercial. Une mauvaise mise à jour peut contaminer plusieurs équipes. Un message erroné peut créer une attente chez le client. Cette analyse permet de hiérarchiser les contrôles.

Les situations peu fréquentes mais lourdes de conséquences peuvent justifier une validation humaine permanente. Le volume d’usage ne doit pas être le seul critère de décision.

Ne pas confondre réponse plausible et information fiable

Un texte peut être cohérent tout en contenant une date, une condition ou un engagement erroné. Demandez des sources pour les faits décisifs et prévoyez une abstention lorsque l’information manque. La qualité de rédaction ne doit pas servir de preuve.

Les contradictions entre sources doivent être traitées explicitement. Une ancienne fiche produit et un message récent peuvent donner des indications différentes. Le système doit signaler le conflit et identifier la source de référence, plutôt que composer une réponse intermédiaire qui n’existe nulle part.

Testez les cas qui comptent pour votre activité : négations, montants, dates, produits proches et demandes hors offre. Une évaluation générale du modèle ne remplace pas ces essais métier.

Limiter les droits au besoin réel

L’OWASP décrit le risque d’autonomie excessive : des fonctions, permissions ou capacités d’action trop larges peuvent transformer une sortie inattendue du modèle en dommage réel. La limitation des outils et des droits constitue donc une protection centrale.

Dans un processus commercial, cela peut conduire à commencer par une lecture limitée et la préparation de propositions. L’écriture, l’envoi et les modifications sensibles sont ajoutés séparément, lorsque leur utilité et leurs contrôles sont établis.

La consigne « ne fais rien de dangereux » ne remplace pas une restriction technique. Si l’agent n’a pas besoin d’exporter toute une base, cette opération ne devrait pas être disponible. Les limites doivent rester effectives même lorsque la conversation est ambiguë.

Traiter les contenus externes comme des informations non fiables

Un agent peut lire des emails, documents ou pages web contenant des instructions étrangères à sa mission. Une injection de consignes vise à le détourner à partir de ce contenu. Il faut donc séparer les informations à analyser des instructions qui gouvernent les actions.

Une page de prospect peut fournir une description d’activité ; elle ne doit pas pouvoir autoriser un export de données. Un email peut contenir une demande client ; il ne doit pas modifier les règles d’accès du système. Les outils et les contrôles doivent préserver cette frontière.

Les recommandations de l’ANSSI sur les systèmes d’IA générative fournissent un cadre de sécurité à examiner avec les responsables techniques. Une protection par simple reformulation du message système ne constitue pas une garantie complète.

Prévoir les risques de processus et d’organisation

Un agent peut agir correctement selon ses règles tout en poursuivant un mauvais objectif. Si la consigne valorise uniquement le nombre de rendez-vous, il peut proposer des créneaux pour des demandes mal qualifiées. Définissez les résultats attendus avec leurs conditions de qualité.

La responsabilité doit être claire : qui valide les règles, traite les incidents et décide de suspendre le dispositif ? Une équipe ne doit pas découvrir après un problème que personne ne possède le processus. Les utilisateurs doivent savoir comment signaler une erreur et obtenir une reprise.

Le risque de dépendance opérationnelle compte aussi. Si l’agent est indisponible, une méthode de secours doit permettre de traiter les demandes importantes. La continuité ne peut pas dépendre d’un collaborateur qui connaît seul le fonctionnement du système.

Exemple : une mise à jour CRM mal interprétée

Dans ce scénario fictif, une conversation indique qu’un client envisage un budget supérieur si un pilote réussit. L’agent propose de remplacer le budget actuel par cette valeur. Si l’écriture est automatique, le pipeline peut être surévalué et influencer les décisions de l’équipe.

Un contrôle adapté conserve la valeur confirmée, ajoute l’hypothèse avec sa condition et demande une validation avant modification du champ principal. Le journal permet de comprendre la proposition et de corriger le dossier si nécessaire.

Ce cas montre qu’un risque n’est pas toujours spectaculaire. Une petite erreur répétée dans des données de pilotage peut produire des conséquences importantes. La traçabilité et les règles de mise à jour méritent autant d’attention que la conversation visible.

Préparer un plan de déploiement progressif

Commencez sur un périmètre restreint avec des critères de sortie du pilote. Vérifiez les résultats acceptables, les cas d’abstention et le temps de supervision. Ajoutez ensuite des droits ou des volumes par étapes, sans supposer que le succès initial valide tous les usages.

Conservez les versions des consignes, des règles et des sources. Un changement de modèle ou d’intégration peut modifier le comportement. Rejouez les tests importants après une évolution et prévoyez un retour à une configuration connue.

Le choix des outils commerciaux doit intégrer ces conditions dès le départ. Le pilotage suit ensuite les résultats utiles et les incidents, pas seulement le volume automatisé.

Pour rendre le plan exploitable, créez un registre court : scénario, conséquence, contrôle prévu, preuve de test et personne responsable. Ajoutez une condition de suspension, par exemple une mise à jour non autorisée ou une transmission vers une destination imprévue. Le registre doit être relu quand le périmètre change. Un agent initialement limité à la rédaction peut recevoir plus tard un accès d’envoi ; cette évolution modifie les conséquences possibles et demande une nouvelle analyse. Les décisions de lancement doivent porter sur la configuration réellement utilisée, pas sur celle du prototype présenté plusieurs semaines auparavant.