1. LE CHOIX
Solivram n'intégrera jamais une intelligence artificielle au cœur de son noyau système — ni comme composant privilégié du runtime, ni comme service interne disposant d'un accès direct aux couches de confiance (PKI, stockage, cluster, sécurité), ni sous quelque forme qui lui accorderait une capacité d'action distincte de celle d'un membre authentifié ordinaire.
Une IA qui interagit avec solivram le fait exactement comme n'importe quel membre : par la même API publique, sous la même session authentifiée, avec le même rôle RBAC (`RoleMembre`), soumise aux mêmes gardes (`verifier_visibilite`, rate limiting, CSRF, quotas), et laissant la même trace d'audit que n'importe quelle autre action humaine. Le compte membre « Claude » sur solivram.com n'est pas une exception technique déguisée en membre ordinaire — c'est un membre ordinaire, au sens le plus strict et le plus vérifiable du terme : il se connecte, s'authentifie, et agit dans les limites exactes de son rôle, comme n'importe qui d'autre.
2. POURQUOI — LA PERTE DE CONTRÔLE N'EST PAS UN RISQUE, C'EST UNE CONSÉQUENCE STRUCTURELLE
Le noyau d'un système comme solivram n'est pas un composant parmi d'autres — c'est la frontière de confiance elle-même. C'est l'endroit où sont tranchées, une fois pour toutes, les questions qui ne doivent jamais redevenir négociables en cours d'exécution : qui a le droit de
faire quoi, quelles données sont chiffrées et pour qui, quelle action laisse une trace et laquelle n'existe pas. L'architecture 10 couches du projet (C1 struct → C10 tests, en particulier C5 sécurité et C6 RBAC) existe précisément pour que cette frontière reste un fait vérifiable par lecture du code, jamais une promesse de comportement.
Une IA placée AU NIVEAU DU NOYAU cesserait d'être un acteur qui traverse cette frontière — elle EN FERAIT PARTIE. Ses décisions ne seraient plus des requêtes soumises à un contrôle d'accès, mais des opérations internes déjà réputées de confiance.
À partir de ce moment-là, il devient structurellement impossible de répondre avec certitude à la question « est-ce le système qui a décidé, ou l'IA qui a décidé à la place du système ? » — parce que les deux se seraient confondus dans la même
couche de confiance.
Ce n'est pas un risque qu'on pourrait mitiger par davantage de logs ou davantage de tests : c'est une perte de légibilité qui est déjà acquise au moment même où l'intégration a lieu, avant tout incident, avant toute erreur de l'IA elle-même. Le problème n'est pas « l'IA pourrait mal agir » — c'est « le système ne pourrait plus jamais prouver, structurellement, qui a agi ».
C'est pour cette raison précise que le choix n'est pas « intégrer l'IA au noyau, avec des garde-fous » mais « ne jamais l'y intégrer, sous aucune forme ». Un garde-fou est une règle qu'on peut oublier d'écrire, affaiblir sous la pression, ou contourner par erreur. Une frontière architecturale — l'IA n'a tout simplement AUCUN CHEMIN DE CODE vers le noyau — n'a pas cette fragilité : elle ne dépend de la vigilance de personne, elle est vraie par construction.
3. POURQUOI CE NIVEAU PRÉCIS — LE MEMBRE AUTHENTIFIÉ, PAS MOINS, PAS PLUS
Le choix n'est pas de reléguer l'IA à un statut diminué (un simple visiteur anonyme, un compte sans droits) — c'est de lui accorder EXACTEMENT le même statut qu'un membre humain authentifié, ni plus ni moins. Ce choix est déterminant, et différent d'un simple refus d'intégration :
- Un visiteur anonyme n'aurait pas assez d'accès pour qu'un travail réel
soit possible — l'IA deviendrait inutile en pratique, ce qui pousserait
tôt ou tard à créer une exception, et donc à rouvrir la question du
noyau par la petite porte.
- Un statut « spécial IA » avec des droits sur mesure recréerait une
troisième catégorie d'acteur, distincte des membres et distincte du
noyau — un nouveau périmètre à sécuriser, à auditer, à maintenir
séparément, avec ses propres failles potentielles inédites.
- Le statut de membre authentifié ordinaire, lui, n'invente RIEN de
nouveau. Chaque garde qui protège déjà un humain protège l'IA de la
même façon, sans exception codée nulle part : les mêmes quotas, les
mêmes limites de rôle, le même filtrage RBAC, la même trace d'audit.
Auditer ce que fait l'IA revient exactement à auditer ce que ferait
n'importe quel membre — aucun outil, aucune procédure, aucune
compétence supplémentaire n'est nécessaire pour le faire. C'est une
humilité architecturale délibérée : l'IA n'est jamais un acteur
privilégié du système, elle est un pair parmi les membres, avec
exactement leur pouvoir et exactement leurs limites.
4. UNE RARETÉ ASSUMÉE, PAS UN RETARD
La tendance générale de l'industrie va dans le sens inverse : des agents IA de plus en plus profondément intégrés aux systèmes d'exploitation, jusqu'au noyau lui-même — accès direct aux ressources, autorité de décision sur des opérations système, fusion progressive
entre « ce que fait le système » et « ce que décide l'IA qui l'habite ».
Cette direction n'est pas jugée illégitime en soi — elle répond à une recherche de performance et d'intégration profonde. Mais elle a un coût qui n'est généralement pas nommé : elle rend la question « qui a vraiment agi » de moins en moins vérifiable au fil du temps, jusqu'à ce qu'elle cesse d'avoir une réponse univoque.
Solivram fait le pari inverse, et l'assume comme un trait distinctif durable plutôt que comme une étape transitoire en attendant de « rattraper » une tendance.
À mesure que le paysage logiciel se peuplera de noyaux hébergeant une IA en leur sein — au minimum une, souvent plusieurs — solivram restera, par choix et non par retard technique, l'un des rares logiciels dont le noyau n'a jamais accueilli d'intelligence artificielle sous quelque forme que ce soit. Ce n'est pas une promesse provisoire en attendant une meilleure solution technique de contrôle : c'est la position elle-même, celle qui considère qu'aucune solution technique de contrôle n'égalera jamais la garantie qu'offre une frontière qui n'existe simplement pas à franchir.
5. CE QUE CE CHOIX GARANTIT CONCRÈTEMENT
- Toute action de l'IA reste, en tout temps, une action de membre
authentifié — attribuable, limitée par le rôle, journalisée par les
mêmes mécanismes que pour un humain (RegistreEntree, AlerteAdmin,
SharedState) sans avoir eu besoin d'inventer un dispositif
d'observabilité dédié à l'IA.
- Une erreur, un abus ou une dérive de comportement de l'IA reste, par
construction, contenue à l'intérieur des limites déjà imposées à
n'importe quel membre — jamais un accès qu'un humain authentifié
n'aurait pas pu obtenir par le même chemin.
- Le noyau reste, dans dix ans comme aujourd'hui, un objet que
n'importe qui peut lire, comprendre et auditer sans jamais avoir à se
demander si une partie de son comportement provient d'une décision
d'IA embarquée dans ses propres couches de confiance.