« On a fait un pilote. Tout le monde a aimé. C’est encore un pilote. »
Le scénario se répète assez souvent pour être prévisible. Quelqu’un monte un prototype en quelques jours, l’ancre sur un dossier de documents copiés à la main, et le présente à la direction. L’accueil est bon. Puis plus rien.
Six mois plus tard, le prototype tourne toujours sur le compte d’une seule personne. Les raisons invoquées restent floues : la sécurité a des réserves, il faut d’abord régler les données, on attend le budget. Sous le flou, il y a toujours les mêmes quatre questions, et personne n’a la réponse.
Au nom de qui l’agent a-t-il le droit de lire un document ? Combien coûte-t-il par mois à volume réel plutôt qu’à volume de démonstration ? À quelle fréquence se trompe-t-il, mesuré contre quoi ? Et qui en est responsable le lundi où la personne qui l’a construit change de poste ?
Ces quatre questions constituent toute la distance entre une démonstration et un système. Elles expliquent aussi pourquoi le deuxième pilote finit habituellement comme le premier.
Pourquoi la réponse habituelle échoue
La réponse habituelle, c’est l’accélérateur IA : une preuve de concept à prix fixe sur quatre à six semaines, montée sur le cadriciel du fournisseur, livrée sous forme de démonstration et de feuille de route. Elle échoue pour une raison précise et répétable : elle est optimisée pour la démonstration.
Un corpus de démonstration ne porte aucune permission. Les documents sont copiés dans un index propre, chaque recherche retourne donc tout, et l’agent paraît remarquablement bien informé. Le jour où cet index est reconstruit sur le vrai parc SharePoint, la recherche se met à retourner la révision salariale, la note d’acquisition et le dossier disciplinaire, parce que rien dans la chaîne ne filtre les résultats selon l’identité du demandeur. L’élagage de sécurité ne s’ajoute pas à la fin. C’est une propriété de la façon dont l’index est construit, et le rattraper revient généralement à refaire la couche de recherche.
Une démonstration s’évalue aussi à l’impression. On la teste avec les questions dont on sait déjà qu’elles passent. Personne n’a monté un ensemble de cas réels avec des réponses attendues validées, alors il n’y a aucun chiffre à défendre quand un directeur demande la précision du système. « Ça avait l’air bon » ne survit pas à un comité de risque, et c’est sain.
La deuxième réponse habituelle est pire : activer Microsoft 365 Copilot et appeler ça un programme d’IA. Copilot est utile, mais c’est autre chose, avec un autre mode de défaillance. L’activer sur un locataire non audité crée un incident de surpartage, pas un agent. C’est un chantier distinct, décrit dans notre approche du déploiement de Microsoft 365 Copilot.
Troisième travers : choisir le cadriciel avant le cas d’usage. Un fournisseur qui vend une plateforme d’agents recommandera sa plateforme d’agents. La décision qui compte, Copilot Studio ou Azure AI Foundry, a une vraie réponse, qui dépend de l’emplacement des données et du contrôle exigé sur le réseau, l’orchestration et l’évaluation. Elle se prend sur le fond d’un cas précis, par écrit.
Comment nous construisons un agent qui reste en production
Le jeu d’évaluation avant l’agent. Trente à cinquante cas réels tirés de vos billets, de vos documents ou de vos décisions, chacun avec une réponse attendue validée. Ça prend environ une semaine et c’est l’artéfact le plus durable du mandat, parce qu’il survit au modèle sur lequel vous avez commencé.
La recherche respecte les permissions existantes. Index Azure AI Search portant les permissions de la source, requêtes filtrées selon l’identité de l’appelant, et une stratégie de découpage et de reclassement ajustée contre le jeu d’évaluation plutôt qu’à l’intuition.
La surface est choisie sur le fond. Copilot Studio quand le contenu est dans Graph et que la tâche appartient à Microsoft 365. Azure AI Foundry quand il faut du réseau privé sur l’inférence, une orchestration sur mesure ou des sources externes. Document Intelligence quand le cas est de l’extraction sur factures, formulaires, contrats ou documents cliniques, là où le rendement est le plus net parce que la référence manuelle se compte déjà en heures.
La frontière est écrite. Ce que l’agent peut faire, ce qu’il ne peut pas faire, ce qu’il doit escalader, ce qu’il journalise. Appliqué dans le code et la configuration, pas suggéré dans une consigne qu’un usager peut contourner en trois phrases. La revue de sécurité de la conception est menée par notre architectes certifiés en sécurité de l’information.
Il tourne où tourne le reste du parc. Inférence dans votre locataire, points de terminaison privés, identité Entra ID, journaux au même endroit que tout le reste. Si ce socle n’existe pas encore, il se construit d’abord : c’est le rôle d’une landing zone Azure.
Le mandat qui livre ça
Un flux de travail, huit semaines, livré en ingénierie IA sur Azure AI Foundry. Les semaines 1 et 2 cadrent le cas d’usage et produisent le jeu d’évaluation et le modèle de coût. Les semaines 3 à 5 construisent la recherche, l’orchestration, les permissions et l’interface, avec du logiciel fonctionnel dans votre locataire chaque semaine. Les semaines 6 et 7 servent à la mesure, aux modes de défaillance, à la revue de sécurité et au comportement en charge. La semaine 8 couvre le déploiement, la surveillance, la documentation et une séance de travail avec l’équipe qui reprend l’agent.
Vous gardez le code applicatif et l’infrastructure en code dans votre dépôt, le jeu d’évaluation, le modèle de coût, la configuration de surveillance et le registre écrit de ce que l’agent peut et ne peut pas faire.
En milieu réglementé, ce travail de frontière occupe l’essentiel du mandat. Un réseau de soins qui déploie un assistant pour son personnel passe plus de temps à décider quels documents sont visibles pour quel rôle qu’à choisir le modèle : c’est pourquoi les projets IA en santé se cadrent autrement, et pourquoi les contrôles se conçoivent en même temps que l’ architecture de conformité. Si le vrai blocage est que les chiffres ne sont pas fiables, la réponse honnête est une modernisation de la plateforme de données, et nous le dirons avant que vous y consacriez huit semaines.
Questions fréquentes
Copilot Studio ou Azure AI Foundry : comment trancher ?
Selon l’endroit où vivent les données et le degré de contrôle exigé. Si le contenu est dans Microsoft Graph (SharePoint, Teams, Outlook) et que la tâche se déroule dans Microsoft 365, Copilot Studio livre en quelques semaines et hérite du modèle de permissions du locataire. S’il faut une orchestration sur mesure, des sources hors Microsoft, un réseau privé sur le point de terminaison d’inférence ou un banc d’évaluation que vous contrôlez, c’est Azure AI Foundry. Nous tranchons en semaine 1 et nous écrivons pourquoi.
Combien de temps avant qu’un agent soit vraiment en production ?
Huit semaines pour un seul flux de travail cadré, du démarrage à un agent déployé avec un responsable nommé, un jeu d’évaluation, la journalisation et une alerte budgétaire. Élargir la portée ne comprime pas ce délai, ça le repousse. Le deuxième cas d’usage va plus vite parce que la tuyauterie d’identité, de recherche et de coûts existe déjà.
L’agent va-t-il exposer des documents que les gens ne devraient pas voir ?
Pas si la recherche applique l’élagage de sécurité : l’index porte les permissions de la source et chaque requête est filtrée selon l’identité de la personne qui pose la question. C’est l’étape que les projets pilotes sautent, parce qu’un corpus de démonstration n’a aucune permission. Sans elle, un agent est une fuite de données avec une fenêtre de clavardage.
Combien ça coûte par mois ?
Nous bâtissons un modèle de coût par jetons pendant le mandat, cas d’usage par cas d’usage, avec un palier de modèle choisi sur la précision mesurée et non sur la réputation. Alertes budgétaires et limites de débit sont en place avant la mise en service. La plupart des charges n’ont pas besoin du plus gros modèle de raisonnement.
Et quand la réponse est fausse ?
Ça arrivera. Nous constituons un jeu d’évaluation de 30 à 50 cas réels tirés de votre historique avant d’écrire l’agent, nous mesurons chaque changement contre ce jeu, et l’interface est conçue pour qu’une personne reste responsable de la décision. Un agent sans banc d’évaluation n’est pas terminé, il est non testé.
Nos données sont en désordre. Faut-il régler ça d’abord ?
En partie. Les cas documentaires fonctionnent souvent sur le désordre tel quel, parce que l’extraction tolère l’irrégularité. Tout ce qui exige des chiffres fiables, non. Nous vous disons lequel des deux vous avez dans les deux premières semaines, et nous ne vendrons pas un agent comme contournement d’un problème de plateforme de données.