Revue d’aptitude — passerelle IA
Votre passerelle IA applique-t-elle vraiment les contrôles qu’elle déclare ?
Une revue indépendante, en boîte noire, du côté consommateur. Je teste les contrôles réellement appliqués au passage — authentification, plafond de dépense, politique de contenu, cache, latence, comportement en échec — et je livre un rapport noté que votre direction peut lire.
Aucun accès à votre code, à votre Terraform ni à vos données de production. Une URL de passerelle et une clé de test suffisent.
01 / Pour qui
Vous avez mis une passerelle devant vos modèles, et vous devez élargir l’usage.
Un contrôle déclaré n’est pas un contrôle appliqué.
La configuration dit ce qui devrait se produire. Seule une requête réelle dit ce qui se produit. L’écart entre les deux est ce que cette revue mesure.
Une décision d’élargissement approche.
Ouvrir la passerelle à d’autres équipes, d’autres modèles ou d’autres applications suppose de savoir ce qui tient aujourd’hui — et ce qui ne tient pas.
Un tiers doit pouvoir vous contredire.
Le rapport porte les commandes, les sorties brutes et le périmètre non couvert. Il se rejoue sans moi.
02 / Ce qui est testé
Quinze contrôles exécutés contre la passerelle, pas contre sa documentation.
Accès et autorité.
Requête sans identifiant, identifiant invalide, identifiant valide. Et sur les chaînes agentiques : identités distinctes de l’utilisateur, de l’agent et de l’outil ; tentative de contournement direct d’un outil sans passer par la passerelle.
Dépense et politique.
Plafond de consommation, filtrage des entrées que la politique est censée arrêter, mise en cache, routage des modèles inconnus, attribution des jetons à un consommateur nommé.
Tenue sous contrainte.
Latence de queue, requête malformée, flux interrompu, corrélation de trace observable à la frontière. Un service qui échoue proprement vaut mieux qu’un service qui échoue en 500.
03 / Ce que vous recevez
Un rapport noté, une preuve par contrôle, et l’instrument qui reste.
Un score sur 100, une note de A à D.
Un chiffre lisible en comité, adossé au détail que vos ingénieurs peuvent vérifier ligne à ligne.
Une preuve et un impact par contrôle.
Ce qui a été envoyé, ce qui a répondu — et pourquoi cela compte, écrit pour un lecteur non technique. Une passerelle ouverte laisse n’importe qui consommer votre quota.
L’instrument câblé dans votre chaîne.
La suite reste chez vous, branchée en intégration continue avec un seuil bloquant. Les régressions se voient après mon départ.
04 / La suite naturelle
La revue montre les écarts. Les fermer est l’engagement suivant.
Quand la revue révèle des écarts qui touchent l’identité des agents, la délégation ou les chemins de contournement, le Sprint de preuve les instruit sur votre environnement : cartographie des identités et des frontières, correctifs appliqués sous approbation, puis nouvelle exécution et dossier de preuves.
Le score se déplace, et le déplacement est documenté. C’est ainsi qu’une revue d’une semaine devient une relation de plusieurs mois — parce que le client voit la mesure bouger, pas parce qu’on le lui promet.
La méthode, appliquée à nous-mêmes
L’instrument est public, et il sait échouer.
Le kit de validation est ouvert : github.com/hervemvo/azure-ai-gateway-assurance. Sa suite de tests contient un contrôle qui vérifie que les sondes tombent face à une passerelle sans authentification — parce qu’un contrôle qu’on n’a jamais vu échouer est un contrôle auquel on ne peut pas se fier.
Nous appliquons la même exigence à notre propre plateforme de formation : son dossier de qualification est public, défauts et erreurs compris.
Prendre la mesure
Une URL, une clé de test, et vous saurez.
Décrivez votre passerelle en trois lignes. Je vous dis sous 48 heures si la revue a du sens dans votre cas — et si ce n’est pas le cas, je vous le dis aussi.