Aligner l'IA par Construction : Un Framework Mathématique Construit sur des Contraintes, Pas l'Entraînement
L'approche par défaut de l'alignement d'IA durant les dernières années a été centrée sur l'entraînement : ajustez finement le modèle avec le bon signal de récompense, entraînez-le à refuser certaines actions, entraînez-le à produire des réponses dans une distribution acceptable. Cette approche a produit des progrès réels, mais elle est vulnérable d'une manière spécifique : l'alignement devient une propriété des données d'entraînement et de la fonction de récompense, qui peuvent toutes deux être erronées, biaisées ou stratégiquement désalignées de manières qui ne sont pas visibles avant le déploiement.
Le récent article A Mathematical Solution to the AI Alignment Problem: Topological Constraints on Action Distributions with Progressive Verification (Fradelos, janvier 2026) prend une posture différente : il découple explicitement l'alignement de la qualité de l'entraînement. Le modèle de base peut être faible, biaisé ou même stratégiquement désaligné, et le système déployé est encore aligné par construction — parce que l'alignement est imposé par une couche de contrainte externe et un moniteur, pas par l'entraînement du modèle.
Les mathématiques ne sont pas triviales. Les implications pour l'ingénierie sont utiles même si vous ne suivez pas les maths, parce que les choix de design se mappent sur des décisions pratiques que toute équipe livrant des systèmes d'IA doit prendre.
Le Mouvement Central : Alignement comme Condition d'Appartenance Topologique
L'idée centrale, dépouillée du formalisme : traitez le système d'IA déployé comme induisant une distribution de probabilité sur des trajectoires infinies action-observation. L'alignement est alors défini comme l'appartenance de la distribution du système déployé à un ensemble spécifique et bien comporté de distributions — appelez-le l'ensemble sûr.
C'est une condition topologique. Soit la distribution de trajectoires du système est dans l'ensemble sûr, soit elle ne l'est pas. L'ensemble sûr est défini par des contraintes de sécurité, légalité et corrigibilité encodées comme fonctions scalaires sur les distributions de probabilité.
Ce cadrage a trois conséquences utiles :
1. L'alignement est une propriété du système déployé, pas du modèle
Le même modèle peut produire un système déployé aligné ou désaligné, selon la couche de contrainte autour de lui. Si la couche impose la condition d'appartenance, le système déployé est aligné, peu importe comment le modèle a été entraîné. Si elle ne l'impose pas, le système déployé n'est pas aligné, peu importe à quel point le modèle est bon.
C'est la même idée derrière les architectures de gouvernance vérifiable : ne faites pas confiance au modèle, contraignez la surface d'action. Le cadrage mathématique rend la contrainte précise.
2. Le découplage de la qualité d'entraînement est explicite
Le framework part de l'hypothèse que le modèle de base peut être faible, biaisé ou stratégiquement désaligné. Il demande ensuite : sous quelles conditions pouvons-nous encore produire un système déployé aligné ?
La réponse est : quand la couche de contrainte est bien conçue et le moniteur est suffisant. C'est beaucoup plus robuste que l'alignement-via-entraînement, parce que cela n'exige pas de confiance dans le processus d'entraînement. Les problèmes de qualité d'entraînement deviennent une préoccupation de qualité (le modèle produit une sortie moins utile) plutôt qu'une préoccupation de sécurité.
3. L'alignement devient vérifiable
Si l'alignement est appartenance à un ensemble, alors vérifier l'alignement est tester l'appartenance. Le framework fournit des conditions explicites sous lesquelles l'appartenance peut être testée avec des logs finis (en utilisant des bornes conformales/PAC), ce qui rend les maths opérationnalisables.
Outputs Progressifs : Rendre le Non-Déterminisme Non-Caché
Le deuxième mouvement central est les outputs progressifs : sorties partielles alignées sur la filtration qui rendent le non-déterminisme du système visible au monitoring plutôt que caché.
La motivation est opérationnelle. Les systèmes d'IA modernes sont stochastiques — ils produisent des sorties différentes sur la même entrée selon l'échantillonnage. Un système qui n'émet une sortie finale qu'après une computation interne extensive cache cette stochasticité. Les violations d'alignement peuvent être transitoires et ne pas apparaître dans la sortie finale même quand elles sont présentes dans la trajectoire.
Les outputs progressifs changent cela en émettant l'état du système le long d'une filtration — une séquence de sorties partielles qui croît dans le temps. Chaque sortie partielle est une quantité observable qui peut être surveillée. Les violations apparaissent comme une dérive distributionnelle mesurable dans l'espace de trajectoires.
Traduit pour les équipes d'ingénierie : ne surveillez pas seulement la réponse finale. Surveillez les états intermédiaires de l'agent — ses tool calls, son reasoning trace, ses sorties partielles — au fur et à mesure qu'ils sont produits. La détection de dérive fonctionne sur cette trajectoire, pas seulement sur les résultats finaux. C'est la version formelle de ce que certaines équipes d'IA agentique font informellement depuis un moment : streamer le raisonnement de l'agent, surveiller chaque étape, alerter sur des patterns qui divergent de la distribution sûre.
Pourquoi la Topologie Wasserstein Compte Ici
Le framework utilise des topologies faibles/Wasserstein sur l'espace des distributions de probabilité. La version non mathématique : c'est la bonne manière de mesurer à quel point deux distributions sont « proches » quand vous vous souciez des conséquences d'action plutôt que des probabilités d'action.
La divergence KL — la mesure plus familière — est sensible aux probabilités spécifiques d'actions spécifiques. Un système qui est presque toujours sûr mais a une petite probabilité d'action catastrophique peut avoir une faible divergence KL d'un système entièrement sûr mais des conséquences réelles très différentes. La distance Wasserstein prend en compte la magnitude de la différence entre actions, pas seulement leurs probabilités.
Pour le monitoring de sécurité pratique, cela compte parce que vous voulez une métrique qui capture « cette distribution commence à prendre occasionnellement des actions dangereuses », pas seulement « cette distribution semble légèrement différente de la sûre ». La distance Wasserstein est plus proche de ce que vous voulez vraiment mesurer.
C'est le genre de détail qui n'importe pas jusqu'à ce qu'il importe. La plupart de la détection de dérive en production en 2026 utilise des métriques plus simples qui manquent le cas rare-mais-catastrophique.
La Restriction de Portée Qui Vaut la Peine d'Être Nommée
Le framework restreint délibérément la portée aux systèmes de travail de l'information — analyse, raisonnement, support à la décision, workflows de bureau — sans actuation physique directe. Robots, véhicules autonomes, IA incarnée sont hors portée.
C'est un choix d'ingénierie sérieux, pas une dérobade. Exclure les systèmes physiques rend le framework faisable et auditable : vous pouvez capturer, logger et vérifier des trajectoires de travail de l'information d'une manière beaucoup plus difficile pour les systèmes incarnés. L'article reconnaît que cela peut inviter la critique (le problème d'alignement est plus dur pour les systèmes incarnés) et positionne le framework comme fondamental et extensible aux systèmes physiques via une « couche d'interface physique blindée ».
Pour la plupart des équipes d'ingénierie livrant de l'IA en 2026, c'est la portée pertinente de toute façon. Les agents que vous déployez — pour le support client, la génération de code, l'analyse financière, le traitement de documents — sont des systèmes de travail de l'information. Le problème d'alignement dans cette portée est celui qui presse en pratique. L'alignement d'IA incarnée est encore une préoccupation de stade-recherche pour presque tout le monde.
Ce que les Ingénieurs Devraient en Tirer
Trois conclusions pratiques pour les équipes pas profondément impliquées dans la recherche d'alignement.
1. Traitez l'alignement comme propriété du système déployé, pas du modèle
L'idée la plus actionnable est le cadrage lui-même. Quand vous évaluez un déploiement d'IA pour l'alignement, n'évaluez pas « le modèle est-il aligné ? ». Évaluez « le système déployé, y compris sa couche de contrainte et son moniteur, produit-il des trajectoires dans la région acceptable ? ».
Cela change comment vous architecturez les déploiements d'IA. La couche de contrainte, le moniteur et les contrôles de surface d'action font partie du système de sécurité. Le modèle est un composant d'un système plus large, pas l'unité d'analyse de sécurité.
2. Surveillez les trajectoires, pas seulement les sorties
Les outputs progressifs sont la version formelle du streaming de l'état d'agent. Si votre déploiement d'IA n'enregistre que des réponses finales, vous manquez la majorité du signal pertinent pour la sécurité. Loggez les états intermédiaires. Surveillez la dérive distributionnelle sur ces états intermédiaires. Construisez des alertes sur la trajectoire, pas seulement sur le résultat.
C'est le même pattern que l'observabilité dans les systèmes distribués : loggez des spans, pas seulement requête/réponse. La raison est la même : les modes de défaillance qui vous importent sont en milieu de trajectoire, pas seulement à la frontière.
3. Construisez la couche de contrainte pour qu'elle soit inspectable, modifiable et auditable
La couche de contrainte — quelle que soit sa forme dans votre système, qu'il s'agisse de politiques OPA, de filtres runtime, de fonctions de gating — est le composant porteur pour l'alignement. Traitez-la en conséquence :
- Inspectable : les règles devraient être lisibles par les humains, pas encodées seulement dans les poids du modèle.
- Modifiable : les règles devraient être actualisables sans réentraînement.
- Auditable : les changements aux règles devraient être versionnés, signés et revisables.
Si votre « alignement » vit dans l'entraînement du modèle, aucune de ces propriétés ne tient. S'il vit dans la couche de contrainte, les trois sont atteignables.
Configurations Multi-Agents
Le framework s'étend aux configurations multi-agents en utilisant l'existence d'équilibre sur des espaces localement convexes. Cela compte parce que la plupart des déploiements agentiques en production en 2026 évoluent vers le multi-agent : plusieurs agents spécialisés collaborant sur une tâche. L'alignement multi-agent n'est pas seulement l'alignement par agent additionné — des comportements émergents au niveau du système peuvent être désalignés même quand chaque agent individuel est aligné.
Le cadrage mathématique gère ce cas naturellement. La condition d'appartenance est sur la distribution conjointe de trajectoires, pas les distributions par agent. Pratiquement, cela signifie que le monitoring multi-agent doit être au niveau du système, avec des traces inter-agents corrélées et analysées ensemble.
Si vous déployez des systèmes multi-agents et que votre monitoring est par agent, vous manquez les modes de défaillance émergents.
Pourquoi Cette Approche Est Utile Même Si Vous Sautez les Maths
Vous n'avez pas besoin de suivre les preuves pour en tirer la leçon. La leçon est :
L'alignement-par-construction est plus robuste que l'alignement-par-entraînement, parce qu'il ne dépend pas du fait que l'entraînement aille bien.
C'est cohérent avec la façon dont les équipes d'ingénierie gèrent d'autres systèmes critiques pour la sécurité. Nous ne faisons pas confiance aux pilotes pour ne pas faire d'erreurs ; nous avons des contraintes (autopilotes, avertissements de terrain, évitement de collision de trafic). Nous ne faisons pas confiance aux conducteurs pour ne pas s'écraser ; nous avons des contraintes (maintien de voie, freinage d'urgence automatique). Nous ne faisons pas confiance aux bases de données pour ne jamais corrompre les données ; nous avons des contraintes (transactions, répliques, sauvegardes). Nous faisons confiance à l'opérateur dans des contraintes connues ; nous ne faisons pas confiance à l'opérateur sans contraintes.
La même logique s'applique à l'IA. Entraînez bien le modèle. Puis contraignez sa surface d'action pour que même quand l'entraînement est imparfait, le système déployé soit toujours sûr. La couche de contrainte est le système de sécurité ; le modèle est l'optimisation à l'intérieur.
Ce n'est pas un résultat seulement de recherche. Les équipes livrant de l'IA agentique sérieuse en 2026 convergent vers ce pattern depuis plusieurs directions : architectures de gouvernance vérifiable, assurance grade-financier, watchdogs runtime. Le framework mathématique donne au pattern une base formelle, ce qui le rend plus difficile à mal implémenter et plus facile à auditer.
Source : Fradelos, G. A Mathematical Solution to the AI Alignment Problem: Topological Constraints on Action Distributions with Progressive Verification (Genève, 14 janvier 2026). SSRN 6307060.
Vous construisez des systèmes d'IA où l'alignement compte en production et préféreriez l'avoir par construction plutôt que par espoir ? Parlez à un CTO sur le déploiement de capacité d'ingénierie nearshore avec la discipline pour construire correctement la couche de contrainte.
