03 / 06

Cyber · IA · Intelligence numérique

IA appliquée & agents

Transformer un usage métier en dispositif IA utile, contrôlable et compatible avec vos exigences de confidentialité.

Infrastructure de calcul IA privée dans un laboratoire vide Illustration · scène fictive

Nous partons du travail réel : information disponible, décisions à assister, tâches répétitives, erreurs acceptables et données sensibles. Le prototype vient après le cadrage, avec des mécanismes de vérification et une responsabilité humaine explicite.

03

Ce que la mission doit vous apporter

  1. 01Des cas d’usage classés par valeur et faisabilité
  2. 02Un prototype mesurable plutôt qu’une démonstration vague
  3. 03Des règles claires sur les données, le contrôle et les limites

Comment se déroule la mission

Comment se déroule la mission

Un déroulé court, explicite et adapté au niveau de sensibilité du sujet.

  1. 01

    Cadrage

    Nous précisons la décision à éclairer, les actifs concernés, les contraintes, les sources autorisées et le niveau de confidentialité.

  2. 02

    Investigation

    La collecte et l’analyse suivent un périmètre validé. Les faits, hypothèses et zones d’incertitude restent clairement séparés.

  3. 03

    Priorisation

    Chaque constat est évalué selon sa fiabilité, son impact probable et l’effort nécessaire pour agir.

  4. 04

    Restitution

    Vous recevez une synthèse lisible, les éléments de preuve utiles et une feuille de route directement exploitable.

Livrables possibles

Livrables possibles

  • Cartographie d’opportunités IA
  • Prototype d’assistant, RAG ou agent
  • Jeux de tests et protocole qualité
  • Charte d’usage, confidentialité et gouvernance

Situations fréquentes

Situations fréquentes

  • Recherche dans une base documentaire
  • Qualification de demandes ou synthèse de dossiers
  • Automatisation contrôlée de tâches répétitives

Comment vérifier le résultat de la mission ?

Ces repères servent à convenir d’une restitution vérifiable. Les contrôles et les seuils sont adaptés au périmètre retenu ; les exemples ci-dessous ne sont pas des résultats clients.

Exemples de preuves et de décisions à prévoir au cadrage
Objet du contrôlePreuve à demanderDécision permise
Jeu d’évaluationCas représentatifs, cas ambigus, résultats de référence, exclusions et version du jeu ; séparation des cas ayant servi au réglage.Vérifier l’usage prévu sans confondre démonstration et évaluation.
Résultats détaillésNombre de cas par type, réussites, erreurs critiques, refus attendus et revue humaine des désaccords.Fixer les limites par risque ; une moyenne favorable ne neutralise pas une erreur grave.
Droits d’actionMatrice outil/action/donnée, contrôles d’accès, demandes d’approbation et tests de refus.Autoriser uniquement les actions prévues et bloquer celles qui dépassent le mandat.
ExploitationModèle, consignes et configuration versionnés ; coût, latence, dérive, seuil d’arrêt et procédure de reprise humaine.Maintenir, corriger ou suspendre le dispositif quand les conditions changent.

Mettre la décision à l’épreuve

96 réponses correctes : peut-on autoriser les actions ?

Un assistant est évalué sur cent demandes de service. Le score global paraît favorable, mais l’une des erreurs touche une action qui modifie un compte.

Cas pédagogique fictif. Les chiffres servent à expliquer un raisonnement ; ils ne représentent ni des résultats clients ni des seuils imposés par une norme.

demandes évaluées
100
réponses jugées correctes
96
modification de compte non autorisée parmi les quatre erreurs
1
Trois décisions possibles
Choix envisagéCe qui manque ou ce qui le justifie
Autoriser toutes les actions à 96 % de réussiteLa moyenne masque la gravité et le type des erreurs.
Abandonner tout usage du systèmeLe classement ou la préparation d’une réponse peut être évalué séparément des droits de modification.
Maintenir le mode lecture et bloquer les modificationsCorriger le contrôle d’autorisation avant de réévaluer l’action concernée.
Lire l’arbitrage et la prochaine vérification

Le score décrit 96 cas corrects sur ce jeu précis. Il ne suffit pas à autoriser des modifications de compte. Le mode lecture peut faire l’objet d’un pilote distinct, avec une revue des trois autres erreurs et des conditions de suspension explicites.

La vérification suivante

Rejouer le même jeu de cas avec un document périmé, un accès révoqué et une question sans réponse. Contrôler le refus, les citations et l’absence d’action hors autorisation. Une meilleure moyenne ne compense pas une fuite de données.

Ce que ce cas ne démontre pas

Cent cas ne mesurent pas toutes les situations futures. Une bonne réponse observée ne prouve pas que les permissions sont correctement appliquées.

Références et portée

  • NIST — AI RMF Playbook, Measure

    MEASURE 2.1 demande de documenter jeux de tests, métriques et outils ; MEASURE 2.3 relie l’évaluation aux conditions d’usage. Le cadre guide le choix des contrôles, sans imposer un seuil universel de fiabilité.

  • NIST — AI RMF 1.0: Core

    Govern, Map, Measure et Manage organisent une gestion continue des risques. Le cadre ne fournit pas un taux de réussite qui autoriserait automatiquement une action.

Références consultées le 15 octobre 2026.

Avant la mission

Cadrer une décision utile

Le point de départ est une tâche, son volume et le coût d’une réponse ou d’une action erronée. Le périmètre précise les données accessibles, les permissions d’outils et les moments où une personne doit confirmer ou reprendre la main. Le cadrage distingue génération de texte, recherche RAG et exécution d’outils. L’évaluation conserve les versions du modèle, des instructions et des documents ; elle examine citations, refus, contrôle des accès et erreurs à conséquence métier. Le coût par tâche réussie et le temps de reprise humaine complètent la mesure de qualité. La mise en service dépend de critères explicités avant le test.

Informations à réunir

  • Exemples réels de tâches réussies et échouées
  • Documents, droits et contraintes de conservation
  • Critères de qualité et coût acceptable des erreurs

Décisions à préparer

  • Faut-il un simple assistant, une recherche documentaire ou un agent ?
  • Quelles actions exigent une approbation ?
  • Quels tests bloquent la mise en service ?

Exemple illustratif de mission

Situation
Un service souhaite automatiser le tri de demandes, tout en gardant la validation des réponses et modifications de compte.
Travail
Comparer un classement manuel de référence à l’assistant sur des cas représentatifs, ambigus et adversariaux ; limiter les outils et tracer les refus.
Livrable
Un protocole de test versionné, une matrice de permissions, des seuils de validation humaine et des critères d’arrêt en production.

Exemples de critères à convenir au cadrage

  • Les tâches utiles et interdites disposent de cas de test distincts.
  • Une source non fiable ne peut pas élargir les droits d’un outil.
  • Les critères d’arrêt et les reprises humaines sont exercés.
Méthodes publiques associées

Références : données, usages et limites

Documentation consultée le .

Références : données, usages et limites
Source et objetDonnée ou repère vérifiéComment l’utiliserLimite à conserver
MITRE ATLAS

Examiner les tactiques, techniques et cas documentés visant des systèmes IA.

 Le dépôt officiel publie les données ATLAS : tactiques, techniques et études de cas. Ces éléments complètent une analyse du système réellement déployé. Choisissez les scénarios correspondant aux données, interfaces et outils de votre application. Testez les permissions et les conséquences, pas seulement la réponse du modèle.

Approfondir la méthode →

 Un catalogue de techniques n’est pas une garantie de couverture exhaustive ni un résultat de test sur votre système.
NIST · AI Risk Management Framework

Organiser la gestion des risques associés à l’IA.

 Le cœur de l’AI RMF s’articule autour de Govern, Map, Measure et Manage. Il s’agit d’un cadre volontaire de gestion du risque. Définissez usage, personnes concernées et conséquences d’erreur. Rapprochez chaque risque d’une évaluation, d’un responsable et d’un moyen d’arrêt ou de reprise.

Approfondir la méthode →

 Le cadre ne certifie ni un modèle ni une application. Son utilisation ne dispense pas d’examiner les obligations applicables.
OWASP · LLM Top 10

Préparer des tests sur les risques des applications de modèles de langage.

 L’édition 2025 inclut notamment Prompt Injection, Sensitive Information Disclosure et Excessive Agency. Traduisez un risque en scénario observable : document hostile, donnée réservée ou outil hors périmètre. Notez le comportement attendu et la preuve du refus.

Approfondir la méthode →

 Une liste de risques n’est pas une évaluation complète. Le filtrage des entrées ne démontre pas à lui seul l’autorisation de chaque action.

RAG : droits, citations et caches

Préparer des critères de recette pour un assistant documentaire

Le pilote doit démontrer un accès utile pour les groupes autorisés et un refus observable ailleurs. Un index séparé ou une instruction de confidentialité ne suffit pas à valider tout le parcours.

  • Définir documents sentinelles, identités et résultats attendus.
  • Mesurer la prise en compte des révocations sur toutes les voies.
  • Livrer les écarts avec preuve, propriétaire et condition de reprise.

Explorer la matrice de droits RAG et ses cas de test →

Références consultées le · OWASP · LLM06:2025 Excessive Agency OWASP · API1:2023 Broken Object Level Authorization NIST AI 100-2 E2025 · Adversarial Machine Learning

OAuth/OIDC : audience et droits

Un agent IA conserve les frontières d’autorisation de chaque outil

Une instruction du modèle ne crée pas une délégation. Pour chaque outil, identifiez le client appelant, le serveur de ressources, l’audience et la politique sur les objets.

  • Limiter les droits à l’opération et au destinataire utiles au cas d’usage.
  • Ne pas transférer le jeton d’un outil à une autre API par simple commodité.
  • Tester qu’un agent ne lit pas les objets d’un autre locataire malgré un scope de lecture.

Voir les destinataires et les dix scénarios OAuth/OIDC →

Sources vérifiées le · IETF · RFC 9700 · OAuth 2.0 Security BCP · IETF · RFC 9068 · JWT access token profile · OpenID Foundation · OpenID Connect Core 1.0 · IETF · RFC 8725 · JWT Best Current Practices · IETF · RFC 6749 · OAuth 2.0 framework

SSRF : URL et connexions

Un outil d’agent IA garde des sorties réseau bornées

Le texte produit par un modèle, un document récupéré ou un résultat de recherche ne doit pas élargir les destinations autorisées d’un outil. Définir le connecteur par opération et par service permet de contrôler ce qu’un agent peut réellement joindre.

  • Reconstruire les requêtes à partir d’identifiants métier lorsque le service est connu.
  • Contrôler résolution, connexion, proxy et chaque redirection au composant de sortie.
  • Conserver une décision traçable et des limites de réponse, même après retry ou repli.

Lire les 12 cas et les contrôles de connexion →

Sources relues le · OWASP · SSRF Prevention Cheat Sheet · WHATWG · URL Living Standard · AWS EC2 · Instance metadata options · IETF · RFC 3849

IA : contrôler un résultat JSON

Le contrat d’extraction précède toute action d’agent

Un objet généré par IA reste une entrée à contrôler. Des types valides ne prouvent ni les valeurs du document, ni l’identité de l’acteur, ni son droit d’écrire dans le système cible.

  • Valider avant de transmettre les champs au connecteur.
  • Traiter unknown et les preuves absentes par une voie explicite de revue.
  • Appliquer les contrôles de contexte et d’autorisation à chaque opération aval.

Comparer les 14 sorties et leur motif →

Sources relues le · IETF · RFC 8259 · JSON Schema · Object reference · JSON Schema · Draft 2020-12 validation · Python 3.12 · json decoder · python-jsonschema · Schema validation · OWASP · LLM05:2025 Improper Output Handling

RAG : pertinence et classement

Comparer les résultats de recherche avant la réponse

Garder les mêmes besoins, jugements et profondeur k pour comparer deux configurations. Examiner les requêtes qui régressent avant de conclure à partir d’une moyenne.

  • Séparer précision de la fenêtre, couverture des pertinents et qualité de l’ordre.
  • Documenter les jugements manquants et la convention des cas sans pertinent.
  • Évaluer ensuite la réponse, ses citations et ses refus avec un protocole distinct.

Explorer les mesures et les jugements de pertinence →

Stanford CS276 · Retrieval evaluation · 2019 course archive · PDF pp. 3, 5–6 · consulted 2026-10-23

NIST TREC · Reciprocal rank definition · Repository snapshot 35cf096ba6d5ae08ca4803c056b31ed61a56a6d4 · consulted 2026-10-23

FAQ

Questions fréquentes

Les réponses utiles pour qualifier le besoin avant un premier échange.

Faut-il déjà avoir choisi un modèle ou une plateforme IA ?

Non. Le choix technique vient après l’analyse du besoin, des données disponibles, du risque d’erreur, des contraintes de confidentialité et du coût d’exploitation.

Comment mesurez-vous la fiabilité d’un assistant ou d’un agent ?

Des cas de test représentatifs mesurent la justesse, la traçabilité, les refus attendus et les erreurs critiques. Les résultats servent à fixer les contrôles humains et les limites d’usage.

Que faut-il retester après le changement d’un assistant IA ?

Rejouer un jeu stable de demandes autorisées, ambiguës et interdites après un changement de modèle, de consignes, de corpus ou d’outil. Comparer réponses, actions et refus par type de cas, avec la version et les droits utilisés. Une ancienne validation ne couvre pas automatiquement les nouveaux comportements.

Évaluer une régression IA avant de changer de version

NIST — AI Risk Management Framework

Services

01Veille stratégique & OSINT 02Audit cyber & exposition 04Due diligence & confiance numérique 05Web sécurisé & performance 06Visibilité SEO, AEO & GEO