Du prototype au changement déployé : intégrer l’IA avec des autorisations limitées

1. Définir la frontière de confiance

Imaginez une fonctionnalité interne qui prépare la mise à jour d’un enregistrement. Le modèle peut lire les informations strictement nécessaires et proposer de nouvelles valeurs pour certains champs, mais il ne reçoit pas les identifiants de la base de données et n’effectue pas la modification. L’application classique garde la maîtrise : elle authentifie la personne, vérifie ses autorisations, contrôle l’état actuel et décide d’appliquer ou non le changement. Cette séparation réduit les conséquences d’une réponse erronée ou manipulée.

Cartographiez le parcours des données avant d’écrire du code. Identifiez ce que la personne envoie, le contexte ajouté, la réponse attendue et les systèmes susceptibles d’être affectés. Considérez les textes récupérés dans des documents, des tickets ou des enregistrements comme des données non fiables : ils peuvent contenir des instructions trompeuses et ne doivent pas élargir l’autorité du modèle. N’incluez pas de secrets ni de données personnelles qui ne sont pas indispensables à la préparation de la proposition.

Définissez une réponse de portée limitée. Au lieu de demander au modèle de mettre à jour un enregistrement, demandez-lui, par exemple, un objet contenant l’identifiant de l’enregistrement, les champs dont il propose la modification et une brève explication. Cette explication peut aider la personne chargée de la vérification, mais elle ne remplace pas les contrôles effectués par le serveur. Le modèle ne doit pas décider qui est autorisé ni quelles règles métier s’appliquent.

L’appel d’outils ou de fonctions permet à un modèle de demander des opérations proposées par une application ; il ne transforme pas cette demande en autorisation. L’application doit interpréter la requête comme une proposition et appliquer sa propre politique. Si la fonction choisie peut modifier des données, l’interface exposée au modèle devrait permettre de préparer l’opération, mais pas de la confirmer.

2. Placer un adaptateur entre le modèle et les services internes

L’adaptateur est du code applicatif qui fait le lien entre la demande de l’utilisateur, l’interface du fournisseur du modèle et les services internes. Il conserve les identifiants, limite le contexte transmis, valide la réponse et n’appelle les opérations métier déterministes qu’une fois les contrôles réussis. Le modèle ne se connecte donc pas directement à la base de données et ne choisit pas la manière d’authentifier une personne.

Séparez les responsabilités en modules compréhensibles : authentification et autorisation ; construction du contexte ; appel au modèle ; validation de la sortie ; présentation pour examen ; et exécution de l’opération après confirmation. Cette séparation permet de changer de fournisseur sans réécrire les règles métier et facilite la désactivation de la génération sans rendre inutilisable la fonctionnalité classique.

Définissez un contrat d’entrée et de sortie versionné. Une réponse structurée peut imposer des champs obligatoires, des types précis et des valeurs choisies dans des énumérations fermées. La sortie structurée aide à réduire les ambiguïtés de format, mais ne prouve pas que les valeurs sont exactes ou sûres. Validez l’objet côté serveur, rejetez les champs inconnus si le contrat l’exige et vérifiez également les règles propres au domaine.

Gardez hors du modèle les décisions qui doivent être déterministes : identité de l’utilisateur, autorisations, limites des ressources, transitions d’état, calculs exacts et écriture persistante. La documentation des plateformes d’intégration présente des modèles de connexion entre modèles et flux de travail, mais la configuration concrète, les connecteurs disponibles et leurs autorisations varient selon le produit. Vérifiez-les dans la documentation à jour du fournisseur.

3. Transformer la proposition en opération autorisable

La réponse du modèle n’est pas une instruction fiable. Avant d’appliquer un changement, vérifiez qu’elle respecte le schéma attendu, que la ressource relève du périmètre autorisé et que l’utilisateur actuel peut effectuer précisément cette opération. Ne déduisez pas une autorisation de l’explication du modèle, d’une catégorie suggérée ou du contenu trouvé dans des documents.

Vérifiez l’état de l’enregistrement juste avant l’écriture. S’il a changé depuis la génération de la proposition, n’appliquez pas silencieusement des valeurs calculées à partir d’une version antérieure. Vous pouvez renvoyer le cas pour examen, générer une nouvelle proposition à partir de l’état actualisé ou présenter un conflit afin que la personne décide. L’écriture doit s’appuyer sur un contrôle de concurrence adapté au système de stockage utilisé.

Définissez des règles métier indépendantes du modèle. Une proposition peut, par exemple, respecter la syntaxe attendue tout en étant interdite parce que le ticket est déjà fermé. Limitez le nombre de champs modifiables, rejetez les valeurs hors plage et empêchez le modèle d’introduire des identifiants de ressources qui n’ont pas été préalablement autorisés.

Une vérification humaine est particulièrement utile lorsque le changement est sensible, difficile à annuler ou affecte d’autres personnes. Elle doit permettre une décision éclairée : présentez les valeurs actuelles et proposées, indiquez les champs qui seront modifiés et permettez l’annulation. Dans les contextes réglementés, les obligations précises dépendent de la fonction et de la classification applicables ; les guides pratiques de l’AESIA concernent la mise en œuvre du règlement sur l’IA et sont présentés comme des recommandations non contraignantes, qui ne remplacent pas la réglementation.

4. Limiter les identifiants, les outils et le contexte

Appliquez le principe du moindre privilège à chaque composant : un identifiant ne doit autoriser que les opérations nécessaires sur les ressources nécessaires. Si le flux doit consulter des données et proposer une mise à jour, séparez l’identité utilisée pour la lecture de celle qui exécute les écritures. Gardez cette dernière hors du processus du modèle et utilisez-la uniquement dans le chemin applicatif contrôlé par le serveur.

N’exposez pas au modèle des outils génériques permettant, par exemple, d’exécuter des requêtes arbitraires, d’accéder à tous les enregistrements ou d’appeler n’importe quelle API interne. Proposez des opérations restreintes, comme obtenir un résumé d’un enregistrement autorisé ou préparer un changement de catégorie. Si la plateforme permet de sélectionner des outils ou des fonctions, cette liste délimite les capacités disponibles ; elle ne remplace pas l’autorisation mise en œuvre par l’application.

Conservez les clés et les jetons dans le système de gestion des secrets approuvé pour votre environnement ; ne les incluez pas dans les instructions, les journaux de débogage ni les réponses aux utilisateurs. Définissez leur rotation et leur révocation, séparez les identifiants selon l’environnement et ne réutilisez pas les clés de développement en production. Les mécanismes de sécurité d’une API — jetons, clés ou certificats — ont des portées et des exigences différentes. Vérifiez celui qui est effectivement configuré dans votre plateforme ; le nom d’un mécanisme ne garantit pas que les autorisations soient minimales.

Réduisez également les informations transmises au modèle. Supprimez les champs sans pertinence, masquez les identifiants lorsqu’ils ne sont pas nécessaires et fixez des limites de taille. Vérifiez quelles données sont envoyées au fournisseur, les conditions actuelles de traitement et de conservation, ainsi que les options disponibles pour la région et le type de service souscrit. Ces éléments varient selon le fournisseur, le produit, la configuration et la date ; ils ne peuvent pas être déduits d’un modèle architectural général.

5. Gérer les délais d’attente, les nouvelles tentatives et les doublons

Un appel au modèle peut être lent, renvoyer une réponse incomplète ou échouer à cause d’une interruption temporaire. Définissez une durée maximale et traitez toute réponse dépassant cette limite comme une proposition indisponible ; n’exécutez pas d’action à partir d’un résultat partiel. Communiquez clairement le statut et permettez une nouvelle tentative sans empêcher la personne de voir ce qu’elle avait demandé.

Distinguez la nouvelle tentative de génération de la nouvelle tentative d’écriture. Une nouvelle demande de proposition peut produire une réponse différente ; conservez donc l’identifiant de la demande et indiquez clairement quelle proposition est en cours d’examen. À l’inverse, répéter une écriture après un délai d’attente peut produire un effet en double si la première requête a bien atteint le système. Utilisez une clé d’idempotence ou un mécanisme équivalent lorsque le service le permet, et vérifiez le résultat avant de renvoyer la requête.

Une opération idempotente produit le même état effectif lorsqu’elle est répétée dans les mêmes conditions ; cela ne signifie pas que toute requête peut être répétée sans conséquence. Pour une écriture non idempotente, prévoyez un moyen de détecter si elle a déjà été appliquée, par exemple en enregistrant l’identifiant de l’opération avec son résultat. Si vous ne pouvez pas déterminer l’issue après une panne, arrêtez les nouvelles tentatives automatiques et soumettez le cas à une réconciliation.

Protégez les écritures contre les changements concurrents. Incluez une version ou une condition correspondant à l’état lu par l’application et rejetez l’écriture si cet état a changé. Définissez ce qui peut être annulé : parfois, il suffit de restaurer des champs ; dans d’autres cas, des effets externes ou des notifications ne peuvent pas être annulés. Précisez alors la mesure compensatoire possible et la personne qui décide de l’appliquer.

6. Déployer par étapes et prévoir une solution de secours

Préparez un environnement de test avec des données non productives ou dûment protégées et des identifiants distincts. Vérifiez le parcours complet : génération d’une proposition, rejet d’une sortie invalide, refus pour autorisation insuffisante, conflit d’état, délai d’attente et échec d’écriture. Il s’agit ici de vérifier le comportement de l’intégration choisie, et non de supposer qu’un fournisseur propose une fonction de sécurité donnée.

Commencez par un mode de proposition sans exécution : l’application peut générer et afficher les résultats, mais elle ne peut pas appliquer les changements. Activez ensuite la confirmation pour un groupe restreint ou une catégorie limitée d’opérations, en désignant les responsables. Définissez à l’avance les conditions d’arrêt de la fonctionnalité, les personnes habilitées à l’activer ou à la désactiver, et la manière de communiquer le changement aux utilisateurs.

Le retour arrière doit être une véritable capacité opérationnelle. Prévoyez un interrupteur qui désactive la génération ou l’exécution d’actions sans modifier les données existantes, un parcours classique permettant d’effectuer la tâche et une procédure d’examen des propositions en attente. Si le déploiement passe par une API ou un pipeline, distinguez le déploiement technique de la publication destinée aux utilisateurs et vérifiez à quelle étape le trafic peut être reçu. Les détails dépendent de la plateforme utilisée.

Avant d’élargir l’accès, consignez les limites connues, les autorisations effectives, le traitement des données et les instructions du fournisseur applicables à la configuration choisie. Les guides de l’AESIA précisent que leurs documents sont des recommandations non contraignantes et qu’ils sont susceptibles d’être révisés ; utilisez-les comme repères contextuels, et non comme un avis juridique s’appliquant automatiquement à toute intégration.

7. Modèle d’examen architectural

Avant de mettre en œuvre la solution, répondez par écrit à des questions vérifiables dans le code, la configuration ou la documentation en vigueur. Ne considérez pas un point comme réglé parce que le fournisseur annonce une capacité générale : confirmez que cette capacité existe dans le produit, la version, la région et le niveau de service que vous utiliserez.

Faites figurer dans l’examen l’interface exacte de l’adaptateur, le schéma de réponse, les règles déterministes, l’identité de chaque composant, les ressources accessibles et le chemin qui mène de la confirmation à l’écriture. Consignez également les scénarios d’erreur, le comportement des nouvelles tentatives, la méthode de détection des doublons, les conditions de concurrence et le mécanisme de désactivation de la fonctionnalité.

Séparez les faits documentés, les décisions de conception et les hypothèses en attente de vérification. Par exemple, le fait qu’une plateforme prenne en charge les appels de fonctions ne prouve pas qu’une fonction donnée puisse être autorisée de manière indépendante. De même, la description de mécanismes d’authentification dans un guide ne prouve pas lesquels sont actifs dans votre déploiement. Vérifiez chaque détail dans la documentation primaire pertinente et dans la configuration effective.

Pour approfondir ces notions, consultez le guide d’apprentissage sur l’IA, le guide des modèles locaux et les fiches du glossaire sur l’appel d’outils, le principe du moindre privilège, la sortie structurée et l’injection de prompt. Ces liens internes doivent mener aux pages d’Inferama et compléter le présent guide ; ils ne remplacent pas la documentation du fournisseur choisi.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.