La recherche dans des colonnes chiffrées sans les déchiffrer est rendue possible grâce à un "blind index". Contrairement à un chiffrement classique non déterministe qui génère un nouveau texte chiffré pour chaque même donnée, le blind index utilise une fonction cryptographique déterministe et secrète (comme HMAC-SHA256) sur la donnée normalisée. Ce mécanisme permet de créer un index sur cette valeur générée, autorisant ainsi les requêtes d'égalité.

L'implémentation dans Symfony/Doctrine consiste à ajouter une colonne supplémentaire à la base de données pour stocker ce blind index, aux côtés du champ chiffré. Lors d'une recherche, le système interroge d'abord la colonne du blind index. Comme la fonction de hachage est déterministe, la même valeur en clair produira toujours le même index. Cependant, en raison de la troncature délibérée de cet index, des collisions sont possibles.

Pour pallier ces collisions et garantir l'exactitude, une étape de vérification est indispensable après avoir récupéré les candidats via le blind index. Le système déchiffre alors le contenu réel de la colonne chiffrée pour les enregistrements correspondants et le compare à la valeur recherchée. Cette approche permet de maintenir la confidentialité tout en autorisant des requêtes efficaces sur les données sensibles.

Le bundle symfony-precognition permet de valider une requête HTTP sans exécuter le code du contrôleur, offrant ainsi une validation de formulaire en temps réel. L'idée principale est de conserver les règles de validation côté serveur, au lieu de les dupliquer côté client, évitant ainsi les incohérences entre les deux implémentations.

Pour ce faire, une requête normale est enrichie d'un en-tête Precognition: true. Le serveur analyse et valide les arguments du contrôleur, mais s'arrête avant l'exécution du code principal. Aucune modification n'est effectuée sur les données ou le système, le client reçoit uniquement un retour sur la validité potentielle de la requête.

Il est possible de limiter les validations retournées à des champs spécifiques grâce à l'en-tête Precognition-Validate-Only, utile pour ne signaler des erreurs que lorsque l'utilisateur a terminé de saisir un champ particulier.

La distinction entre les "sub-agents" et le "Master Control Panel" (MCP) est cruciale pour l'architecture des systèmes d'IA. Historiquement, la confusion a conduit à mélanger la fonction de raisonnement ("qui pense") et celle d'exécution ("qui agit"), entraînant des problèmes de gouvernance, de traçabilité et de permissions.

Un sub-agent est conçu pour un rôle cognitif spécialisé, recevant un prompt, un périmètre et des règles pour produire une sortie structurée et utile. Il se concentre sur la pensée critique et la formulation. À l'inverse, un serveur MCP est une infrastructure dont le rôle est d'exécuter des actions de manière contrôlée, en exposant des capacités et des données avec des contrats clairs et une traçabilité.

Cette séparation est particulièrement pertinente lors de la gestion d'incidents. Dans un modèle bien conçu, un orchestrateur délègue des tâches à des sub-agents spécialisés (diagnostic, mitigation), qui formulent des hypothèses et proposent des actions. L'exécution réelle de ces actions est ensuite gérée par les serveurs MCP appropriés, laissant une trace écrite et permettant de comprendre précisément qui a décidé quoi et pourquoi.