Une automatisation IA naît souvent hors du produit : script qui résume des dossiers, scénario d’orchestration qui classe des courriels ou notebook qui prépare une réponse. Le problème apparaît quand l’expérimentation devient indispensable au parcours. Les utilisateurs ne savent plus si la proposition a été enregistrée, les droits divergent et le support jongle entre l’application, le fournisseur de modèle et un tableau annexe.
Le vrai enjeu n’est pas de choisir entre « intégré » et « externe » par préférence d’architecture. Il faut placer l’automatisation là où son état, ses droits et sa responsabilité peuvent être assumés. Dans une application web métier construite sur mesure, l’interface peut appartenir au produit tandis que l’inférence reste un service séparé ; inversement, un batch autonome peut écrire une proposition dans le produit sans en devenir le système de référence.
Contre-intuitivement, afficher l’IA dans l’écran principal ne la rend pas intégrée. L’intégration existe lorsque l’utilisateur comprend son statut, peut contester sa sortie, retrouve la source et sait ce qui se passe en cas d’indisponibilité. La méthode permet de décider le placement à partir de la promesse, du risque et du run, puis de garder un chemin de retour.
Définir ce que signifie vivre dans le produit
Distinguer expérience, décision et exécution
Une fonction peut vivre dans l’expérience produit sans que le modèle soit exécuté dans le même processus. Le produit possède alors le bouton, l’état, les droits et la validation ; un service spécialisé reçoit une requête versionnée et renvoie une proposition. Cette séparation protège l’interface contre les détails du fournisseur.
À l’inverse, une automatisation hors produit peut rester légitime si elle prépare une file de travail sans modifier une décision opposable. Elle dispose néanmoins d’un owner, d’un contrat d’entrée et d’une sortie traçable. « Externe » ne signifie ni invisible ni dispensé de gouvernance.
Partir de la promesse faite à l’utilisateur
Décrivez ce que l’utilisateur attend : obtenir une suggestion pendant qu’il rédige, retrouver des dossiers classés le lendemain ou recevoir une alerte à vérifier. La tolérance à la latence, au silence et à l’erreur change avec cette promesse. Une aide rédactionnelle peut échouer sans bloquer ; une orientation de dossier urgente exige un état explicite et un repli.
La promesse précise aussi la population et la conséquence. Si l’IA modifie seulement l’ordre d’une liste personnelle, le risque est limité. Si elle influence une priorité, un accès ou une somme, la validation, l’explication et l’audit prennent le dessus. Le placement suit cette responsabilité, pas la visibilité de la fonctionnalité.
Séparer suggestion probabiliste et décision métier
Persistez la sortie IA comme une proposition avec modèle, version de prompt, sources et score éventuellement disponible. La décision métier reste un événement distinct, attribué à une personne ou à une règle déterministe. Cette distinction permet d’améliorer le modèle sans réécrire l’historique des décisions.
Si une action automatique est acceptée, documentez précisément son périmètre et ses exclusions. Une classification à faible impact peut déclencher un routage réversible ; un refus, une suppression ou un engagement financier exige généralement un contrôle plus fort. Le terme « humain dans la boucle » ne suffit pas : il faut savoir quand il intervient, ce qu’il voit et quel pouvoir réel il possède.
Choisir où assembler le contexte nécessaire
Le produit connaît souvent l’utilisateur, le dossier ouvert, les droits et l’état courant. Exporter ce contexte vers une orchestration séparée peut multiplier les copies et produire une réponse sur des données périmées. À l’inverse, charger toute la logique d’enrichissement dans le front ou le contrôleur rend le parcours difficile à tester.
Créez un contrat de contexte minimal : identifiants, version, fragments autorisés et références de sources. Le service résout les dépendances dont il est responsable et indique ce qu’il a réellement consulté. Le produit refuse une proposition calculée sur une version devenue obsolète ou demande une nouvelle évaluation.
Appliquer les mêmes droits que le parcours principal
L’automatisation ne doit pas élargir l’accès sous prétexte qu’elle travaille pour l’utilisateur. Le produit vérifie l’autorisation de demander l’action ; le service accède uniquement aux sources nécessaires avec une identité et un périmètre connus. Les documents de récupération respectent les droits du dossier au moment de l’inférence.
Testez retrait de rôle, changement d’entité et ressource partagée. Une réponse mise en cache ne doit pas révéler un contenu qu’un utilisateur ne peut plus consulter. Les journaux et jeux d’évaluation excluent ou protègent les données sensibles selon une politique explicite.
Arbitrer interaction synchrone et traitement asynchrone
Ne pas immobiliser le parcours sur une inférence longue
Un appel synchrone convient si l’utilisateur attend la proposition, si le budget de réponse est compatible avec le parcours et si un échec peut être expliqué immédiatement. Fixez un timeout inférieur au budget de l’écran et proposez une action sans IA lorsque c’est possible.
Pour les traitements longs ou en volume, enregistrez l’intention et passez par une file. Le produit affiche en attente, disponible, à revoir ou échoué. Il ne prétend pas que le travail est terminé parce que le message a été accepté. L’âge du plus ancien élément et la fraîcheur de la proposition deviennent des signaux de run.
Limiter le couplage au modèle et au fournisseur
Une interface interne décrit la capacité — résumer, extraire, proposer une catégorie — plutôt que l’API d’un modèle. L’adaptateur traduit paramètres, outils, formats et erreurs. Le produit consomme un schéma métier versionné et ne dépend pas de champs propres au fournisseur.
L’abstraction doit rester honnête : les modèles n’ont pas tous les mêmes capacités ni comportements. Conservez des adaptateurs explicites et un jeu d’évaluation commun, sans promettre un changement instantané. Le fallback peut être un modèle différent, une règle classique ou une file humaine selon le cas.
Le coût caché d’un couplage direct se révèle lors d’un changement de modèle : reprise des écrans, des tests, du monitoring et des procédures de support. Il augmente aussi la charge de diagnostic quand chaque appel utilise ses propres paramètres. Centraliser le contrat permet de mesurer le coût par capacité et l’impact business des indisponibilités, sans prétendre que tous les fournisseurs sont interchangeables.
Gouverner données, prompts et sorties
Cartographiez les données envoyées, leur finalité, leur durée et leur région de traitement. Vérifiez les conditions contractuelles et paramètres du service réellement utilisé. Limitez les entrées à ce qui sert la tâche ; remplacez les secrets et identifiants inutiles par des références ou des valeurs synthétiques.
Versionnez les templates de prompt avec le code ou une configuration gouvernée. La sortie brute n’est pas toujours un enregistrement métier : validez son schéma, sa taille et ses références avant de la persister. Définissez la conservation séparément pour demande, réponse, traces techniques et preuve de décision.
Évaluer le système sur des cas versionnés
Constituez un jeu représentatif des cas fréquents, ambigus, sensibles et hors périmètre. Chaque cas porte une attente observable : catégorie acceptable, source obligatoire, information interdite ou décision de renvoi humain. Les exemples sont revus par le métier et protégés comme des données de test.
Comparez les versions sur précision utile, taux d’abstention, corrections, latence et coût. Une moyenne globale masque les classes rares qui engagent le plus de risque. Le go dépend de seuils par segment et d’une analyse des erreurs, pas d’une impression lors de quelques démonstrations.
Cas concret : préqualifier une demande de support
Un éditeur reçoit des demandes par portail. L’équipe veut proposer produit, urgence et équipe responsable. L’IA ne ferme aucun ticket et ne modifie aucun droit. Le produit enregistre la demande, puis publie une intention de préqualification avec la version du texte et les pièces autorisées.
Le service produit une proposition, des sources et un motif d’abstention éventuel. Si le ticket a changé entre-temps, le produit marque la réponse obsolète. Un agent accepte, corrige ou ignore ; son action alimente l’évaluation sans être envoyée automatiquement à un entraînement.
Par exemple, si plus de 8 % des incidents de sécurité sont routés hors de la file dédiée pendant une semaine de pilote, alors cette classe repasse en règle explicite et revue humaine. Le chiffre est un seuil local lié au risque de cette équipe, pas un taux de qualité universel.
Construire une frontière produit-service explicite
Le produit possède l’intention, l’état utilisateur et la décision. Le service IA possède la préparation du contexte, l’appel au fournisseur, la validation technique de sortie et les métriques d’inférence. Un identifiant de corrélation relie les deux sans faire du journal du fournisseur une source métier.
Le contrat prévoit acceptation, résultat, erreur transitoire, refus de politique et sortie invalide. Les callbacks ou événements sont idempotents ; une réponse répétée ne crée pas deux propositions. La version du dossier empêche d’appliquer un résultat ancien à un état nouveau.
Mettre en œuvre états, contrats et responsabilités
Rendre chaque étape testable hors du fournisseur
L’entrée contient l’identifiant d’intention, la version du dossier, la capacité demandée et le contexte autorisé. La sortie contient un statut, une proposition structurée, les références de sources, les versions et un motif d’abstention. Le contrat refuse les champs inattendus au lieu de les afficher.
La responsabilité du produit couvre autorisation et décision ; celle du service couvre dépendances, retry borné, validation et journalisation. Le monitoring suit latence, erreurs, âge de file, sorties invalides et corrections. Le seuil d’arrêt bascule vers le repli sans cacher l’indisponibilité.
Les tests utilisent un fake pilotable pour timeout, contenu invalide, réponse répétée et changement de version. Quelques essais contrôlés confirment le fournisseur réel. La recette rejoue les cas sensibles avec les mêmes droits que la production.
Préparer fallback, rollback et reprise
Continuer le métier sans inventer une réponse
Le fallback peut masquer la fonction, garder une saisie manuelle, appliquer une règle déterministe ou placer le dossier en attente. Il dépend de la promesse. Une réponse générique présentée comme vraie n’est pas un mode dégradé acceptable.
Le rollback restaure version de prompt, adaptateur ou modèle, mais ne réécrit pas les décisions déjà prises. La reprise identifie les intentions en attente et les propositions obsolètes, puis les rejoue ou les abandonne selon une règle. Le support voit la prochaine action autorisée.
Pour qui cette décision d’architecture est utile
Elle concerne product owners, responsables métier, architectes, équipes data ou IA, sécurité, DPO, développeurs et support. Elle devient prioritaire quand un prototype quitte le laboratoire, quand une sortie influence une décision ou quand plusieurs applications appellent la même capacité.
Pour une expérimentation isolée sur données synthétiques, le dispositif peut être plus léger. Dès qu’un résultat entre dans le parcours ou persiste, les états, droits et responsabilités doivent être explicites. Si aucun owner ne peut assumer le run, la fonction reste hors production.
Erreurs fréquentes de placement d’une automatisation IA
- Appeler le modèle directement depuis l’interface. Secrets, retry et état utilisateur deviennent difficiles à contrôler.
- Écrire la sortie comme une vérité. La proposition probabiliste efface la décision et sa contestation.
- Dupliquer tout le contexte dans un outil externe. Les droits et versions divergent.
- Créer une abstraction de fournisseur trop générique. Les différences réelles disparaissent jusqu’à l’incident.
- Mesurer seulement l’acceptation. Latence, abstention, corrections par classe et coût restent invisibles.
- Utiliser un fallback silencieux. L’utilisateur ne sait plus si la réponse vient du modèle, d’une règle ou d’un humain.
Arbitrer avec une matrice produit ou service
Évaluez proximité avec l’interaction, besoin de contexte frais, droits, conséquence d’erreur, latence, fréquence, volume, réutilisation, audit et indépendance du fournisseur. Chaque axe cite un scénario ou une mesure. L’option peut être intégrée, séparée ou hybride.
- Dans le produit pour l’état, l’autorisation, l’explication et la décision visibles.
- Dans un service pour l’inférence, les adaptateurs, les files et l’évaluation partagés.
- Dans une automatisation opérée pour un traitement réversible hors parcours avec contrat et owner.
- Hors production si les données, la responsabilité ou le repli ne sont pas encore maîtrisés.
Qualifier des seuils locaux de qualité et de coût
Le seuil dépend de la classe et de la conséquence. Une équipe peut accepter davantage de corrections sur un brouillon que sur un routage urgent. Mesurez par population, version et période ; conservez la baseline manuelle pour savoir si l’automatisation améliore réellement le processus.
Cas de figure : si la latence au 95e percentile dépasse le budget local de 6 secondes pendant trois jours, alors l’écran passe en mode asynchrone plutôt que d’allonger son attente. Si le coût par dossier double sans réduire les corrections, le lot revient au palier précédent. Ces valeurs illustrent des décisions qualifiées, pas des recommandations générales.
Plan d’action : décider le placement en huit semaines
Aller de la promesse au run prouvé
La séquence est adaptable à la criticité. Le sponsor borne une capacité et désigne responsables produit, métier, IA, sécurité et exploitation. Le dossier commun conserve contrats, jeu d’évaluation, mesures, limites et décisions.
Chaque semaine répond à une question de placement. Une preuve manquante réduit le périmètre ; elle n’est pas compensée par une démonstration supplémentaire.
- Semaine 1 : décrire promesse, utilisateurs, décisions, erreurs acceptables et fonctionnement sans IA.
- Semaine 2 : cartographier données, droits, sources, conservation et conditions du fournisseur.
- Semaine 3 : constituer le jeu d’évaluation avec cas ambigus, sensibles et hors périmètre.
- Semaine 4 : prototyper le contrat produit-service et les états visibles, avec un fake pilotable.
- Semaine 5 : mesurer qualité par classe, latence, abstention, corrections et coût sur le fournisseur réel.
- Semaine 6 : provoquer timeout, quota, réponse invalide, doublon et dossier devenu obsolète.
- Semaine 7 : faire exécuter fallback, rollback et reprise par les équipes de run.
- Semaine 8 : choisir le placement, fixer seuils et owner, puis borner un lot réversible.
Le go exige que l’utilisateur distingue proposition et décision, que les droits soient identiques au parcours et que le support puisse retrouver une intention. Le verdict précise aussi ce qui ferait changer d’architecture.
Après trente jours, la revue compare les corrections, incidents et coûts à la baseline. Après quatre-vingt-dix jours, elle confirme le placement ou déplace une frontière sans réécrire l’ensemble du produit.
Le responsable produit publie enfin le schéma d’entrée et de sortie, les owners, les dépendances, les seuils et le runbook. Cette synthèse devient le contrat de la première version ; toute nouvelle capacité repasse par la même décision au lieu d’hériter automatiquement du placement initial.
S’appuyer sur des références primaires pour l’IA
Le NIST AI Risk Management Framework fournit un cadre primaire pour gouverner, cartographier, mesurer et gérer les risques. La CNIL rassemble ses ressources sur IA et RGPD pour les traitements de données personnelles.
La Commission européenne présente le cadre réglementaire européen de l’IA. La qualification juridique dépend du système et de son usage : une architecture technique ne remplace pas l’analyse de conformité menée par les personnes compétentes.
Relier placement, usages et responsabilité humaine
Les cas d’usage crédibles de l’IA générative aident à choisir la première capacité. Le workflow humain plus IA précise la validation et la contestation.
Pour les documents, l’extraction et le routage assistés fournissent un cas plus spécialisé. Ces lectures complètent le choix d’architecture sans imposer un même placement à toutes les fonctions.
- Qualifier l’usage avant de choisir le fournisseur.
- Séparer proposition, validation et effet métier.
- Conserver un repli exploitable à chaque frontière.
Conclusion : intégrer la responsabilité avant l’interface
Une automatisation IA vit dans le produit lorsque son état, ses droits et sa proposition appartiennent au parcours. Son inférence peut pourtant rester dans un service séparé. À l’inverse, un traitement hors produit reste acceptable s’il possède un contrat, un owner et une reprise.
Le placement solide rend la décision contestable, les données gouvernées et le fournisseur remplaçable à un coût connu. Il évite de confondre visibilité de l’interface et maîtrise de la chaîne.
Cette frontière doit rester lisible dans le code, les écrans et le runbook afin que son évolution demeure une décision consciente.
Si votre expérimentation IA entre dans un processus critique, Dawap peut vous accompagner pour cadrer ses frontières, construire son évaluation et l’intégrer dans une application web métier responsable et exploitable.
