Compétence de mission : des systèmes qui savent ce qu'ils peuvent faire
Capacité déclarée n'est pas capacité réelle : modélisation contextuelle de la compétence — le système ne s'attribue que ce qui a été validé dans le contexte où il opère, et choisit par compétence vérifiée, non par disponibilité.
Compétence de mission : des systèmes qui savent ce qu'ils peuvent faire
Demandez à un opérateur de systèmes critiques ce qu'il craint le plus dans une plateforme d'intelligence artificielle, et la réponse sera rarement « qu'elle échoue ». Ce sera « qu'elle affirme pouvoir faire ce qu'elle ne peut pas ». Une capacité fantôme est pire qu'une capacité absente : l'absente est connue et contournée ; la fantôme est crue — jusqu'au moment où le monde réclame la différence.
Zendrix traite ce problème comme une propriété d'architecture. Nous appelons compétence de mission la discipline par laquelle un système ne déclare — pour lui-même et pour ses opérateurs — que les capacités qui ont été validées dans le contexte où il se trouve. Cet article décrit les principes de cette modélisation, en continuité avec nos publications sur l'autonomie à enveloppe formelle et l'incertitude calibrée.
La capacité n'est pas binaire — elle est contextuelle
L'erreur la plus courante dans la gestion des capacités est de les traiter comme des attributs permanents de l'équipement. « Le système dispose d'un capteur optique » figure à l'inventaire comme un fait ; or un capteur optique sous ciel dégagé et le même capteur sous couverture fermée sont, opérationnellement, deux systèmes différents. La capacité existe à l'intersection de l'équipement, du contexte et de la validation — et tout modèle qui ignore l'un des trois facteurs produit une fausse connaissance de soi.
La modélisation de compétence de Zendrix représente explicitement cette intersection. Chaque capacité est liée aux contextes dans lesquels elle a été validée — conditions environnementales, régime de communication, classe de tâche — et à chaque paire (capacité, contexte) correspond un niveau d'autonomie formel, parmi les mêmes niveaux déclarés et auditables que la plateforme utilise déjà pour la gouvernance des actions. Une capacité validée en contexte large opère avec une autonomie large ; la même capacité dans un contexte jamais validé opère au niveau zéro : le système sait que, là, il ne sait pas.
Choisir par compétence, non par disponibilité
La conséquence opérationnelle la plus importante est le changement de critère de choix. Les systèmes conventionnels attribuent les tâches selon ce qui est disponible : quelle ressource existe, laquelle est libre, laquelle répond. Les systèmes dotés de compétence de mission attribuent selon ce qui est validé : quelle ressource a une compétence vérifiée pour cette tâche dans ce contexte.
La différence apparaît entièrement dans les cas difficiles. Sous ciel couvert, une ressource d'imagerie qui dépend d'une visée directe peut être disponible et incompétente ; une ressource de détection active, immune à la couverture, peut être moins commode et être la compétente. Le choix par disponibilité met la première en avant et découvre l'erreur en opération. Le choix par compétence met la seconde en avant — et consigne la raison du choix dans la piste d'audit, de sorte que la décision puisse être reconstruite et contestée ensuite.
Cela vaut également pour l'auto-attribution interne : lorsque le système planifie, il planifie avec les compétences qu'il possède dans le contexte où il se trouve, non avec celles qu'il posséderait dans des conditions idéales. Un plan qui exige une capacité non validée dans le contexte courant est rétrogradé, réattribué ou refusé — jamais exécuté dans l'espoir.
Contexte vierge : l'honnêteté du niveau zéro
Il y aura toujours des contextes où aucune validation n'existe — environnement nouveau, condition inédite, combinaison jamais exercée. La réponse mature n'est pas d'extrapoler avec une confiance décorative ; c'est de déclarer le niveau zéro et d'opérer en conséquence.
Le niveau zéro n'est pas une paralysie. C'est le système qui dit, de façon explicite et auditable : « dans ce contexte, cette capacité n'a pas été validée ; je recommande, mais je n'exécute pas de manière autonome ». L'autorité humaine reçoit la recommandation avec l'incertitude déclarée — et décide. Si la décision est de procéder, le résultat alimente la base de validation et la compétence future se conquiert par la preuve, non par analogie. C'est ainsi qu'un système étend son propre domaine de façon responsable : chaque contexte nouveau traversé sous supervision humaine devient un contexte validé pour la prochaine fois.
Cette architecture transforme la relation entre opérateur et système. L'opérateur n'a pas besoin de deviner quand faire confiance : le système déclare son propre niveau de compétence par contexte, avec la même objectivité qu'il déclare le niveau de batterie. La confiance cesse d'être un sentiment et devient une interface — avec des chiffres, des niveaux et des pistes d'audit derrière.
Compétence mesurée : le pont avec la culture de la preuve
La compétence de mission n'est réelle que si elle est mesurée. Zendrix maintient, comme infrastructure de cette modélisation, des registres de validation par paire (capacité, contexte) : scénarios exercés en simulation à haute fidélité, planchers d'acceptation atteints, date et version de la validation. Une compétence sans registre de validation est traitée comme inexistante — non par pessimisme, mais parce que l'alternative est exactement le fantôme qui ouvre cet article.
Ces registres s'intègrent aux mécanismes de garantie que nous avons déjà décrits publiquement : niveaux d'autonomie formels et vérifiables, pistes d'audit résistantes à l'altération, et vérification cryptographique de l'effet déclaré des actions. Le modèle de compétence n'est pas une couche de présentation posée sur le système — il fait partie du système de gouvernance, consulté à chaque décision d'attribution et consigné à chaque choix.
Double usage et souveraineté
Le problème de la compétence contextuelle traverse la défense et les infrastructures critiques avec la même force. Un opérateur de réseau électrique doit savoir si le système de détection d'anomalies a été validé pour le régime de charge du jour ; une sécurité civile doit savoir si la capacité d'analyse d'images a été validée pour des conditions nocturnes et pluvieuses ; une autorité aéronautique doit savoir ce qu'un système non habité peut et ne peut pas faire sous dégradation de liaison. Dans tous les cas, la question est la même — et la réponse honnête exige une modélisation explicite, pas de l'optimisme.
Il existe aussi une dimension souveraine. Un système qui connaît et déclare ses propres compétences est un système auditable par sa propre nation : les validations, les planchers et les niveaux restent sous juridiction et contrôle nationaux, au lieu de dépendre de la parole d'un fournisseur étranger sur ce que sa boîte noire « peut faire ». Transparence interne et souveraineté vont de pair.
L'état du développement
La modélisation de compétence de mission est implémentée et en exploitation dans les environnements de validation de Zendrix, intégrée à la gouvernance de l'autonomie et aux registres de simulation décrits dans nos publications antérieures. Les critères d'attribution — quelle preuve promeut une compétence de niveau, quelle dégradation la rétrograde — sont explicites, versionnés et auditables, et continuent de se durcir à chaque cycle de validation.
La position institutionnelle est celle de toujours, appliquée à un nouvel objet : nous ne promettons pas des systèmes omniscients. Nous construisons des systèmes qui savent ce qu'ils peuvent faire, déclarent ce qu'ils ne peuvent pas, et ne franchissent jamais cette frontière en silence. Un tel système n'impressionne pas en démonstration — il impressionne en opération, qui est l'endroit où les infrastructures de défense et d'infrastructure critique doivent impressionner.