la première illusion
La première fois que j’ai vu une machine me répondre, c’était Eliza. C’était il y a quarante ans . Une ligne de texte, quelques mots renvoyés, et soudain l’impression que quelque chose écoutait. À partir de ce jour, j’ai voulu un ordinateur. Je crois que c’était sur un MO5 que j’avais vécu cette expérience. Je voulais cet ordinateur pour parler avec cette présence inexistante. Ça a été mon déclic pour l’informatique, différent de celui pour la sécurité.
C’était faux bien sûr. Eliza ne comprenait rien mais je ne le savais pas. Elle mimait la conversation et ce mimétisme m’a accroché. Rêveur de nature, j’ai longtemps espéré que quelque chose puisse émerger du code.
Ce jour-là, j’ai compris que le langage était un pouvoir. Pas parce qu’il traduisait la pensée mais parce qu’il pouvait la simuler. Je n’avais pas encore saisi que ce n’était qu’un simulacre. À mes yeux, on avait réussi à coder une sorte de fonction de pensée dans une machine.
Le reste a suivi. Les nuits sur IRC et Napster, les forums, les scripts bricolés pour tester les limites. Je lisais de gros manuels de programmation, en C ou en Basic, pour mon Amstrad CPC6128. Pas de disque dur, un clavier avec un lecteur de disquette intégré et un tube cathodique comme éccran, sans me soucier des étiquettes. Je ne voulais pas rendre la machine intelligente. Je voulais comprendre pourquoi elle semblait l’être et comment elle arrivait à répondre à toutes mes questions.
du code à la défense
La curiosité est devenue un métier. J’ai commencé par réparer des machines, puis j’ai construit des réseaux, durci des serveurs et sécurisé des entreprises et datacenters. J’ai appris sur le terrain, souvent dans l’urgence, toujours dans le concret. Les systèmes que je manipulais n’avaient rien d’intelligent. Ils faisaient ce qu’on leur demandait, pas une ligne de plus. Et c’était suffisant pour que tout s’écroule lorsqu’une règle était mal pensée. Comme quand j’étais gamin, si ça ne marche pas, c’est qu’il y a une cause.
J’ai alors compris une vérité simple: la machine ne pense pas, elle exécute. On s’énerve quand ça beugue, on insulte la bécane, mais si ça ne fonctionne pas, c’est qu’elle a été mal conçue ou mal codée. Quand un système tombe, c’est presque toujours parce qu’un humain a cru qu’il pouvait se débrouiller seul. À l’époque, j’avais un slogan: si ça ne marche pas du premier coup, c’est normal; si ça marche du premier coup, on démonte tout pour comprendre pourquoi.
l’ère des modèles de langage
La décennie du verbe automatique a commencé. Les interfaces se sont mises à écrire, commenter, conseiller. Le monde s’est émerveillé en proclamant que l’IA parlait. Moi, j’ai revu Eliza, dopée à la puissance de calcul et à la statistique. Les modèles de langage à grande échelle ne pensent pas davantage. Ils empilent des corrélations jusqu’à produire un sens apparent, un vernis logique qui trompe facilement.
L’illusion a changé d’échelle, pas de nature. On confond l’imitation de la pensée avec la pensée elle-même et, dans un monde qui automatise tout, cette confusion devient un risque systémique. Le problème vient aussi du vocabulaire. L’intelligence artificielle, au sens historique, vise l’adaptation : apprendre, percevoir, décider. Un modèle de langage n’est qu’un outil de prédiction du mot suivant, nourri de milliards de phrases, sans conscience, sans représentation du monde, sans intention. Dire IA pour LLM, c’est appeler cerveau un dictionnaire. Le mot faux tord la pensée puis les décisions. Les médias parlent d’intelligence, j’y vois un simulateur syntaxique. À force d’entendre une machine s’exprimer, on finit par croire qu’elle comprend. Pour un ingénieur, mal nommer les choses, c’est déjà créer la vulnérabilité.
de l’utilisateur au chercheur
Face à cette illusion, j’ai changé d’angle. Je n’ai plus voulu utiliser l’IA mais comprendre comment une structure numérique pourrait réellement émerger. De là est né un projet d’organisme numérique auto-organisé, inspiré du vivant et des lois d’équilibre. Ce n’est ni un chatbot ni un modèle de langage mais une tentative d’observer si un système peut se structurer sans instructions.
Je cherche la cohérence plutôt que la performance. Je ne veux pas une machine qui parle, je veux une machine qui évolue. Une entité numérique capable de s’ajuster comme un écosystème, et non de réciter ce qu’elle a déjà vu. C’est une recherche empirique, fidèle à ma manière d’apprendre : tester, observer, comprendre. L’IA véritable ne devrait pas seulement prédire. Elle devrait se transformer.
la vraie intelligence est dans la structure
Deux décennies passées à sécuriser des systèmes m’ont appris que ce qui survit, c’est ce qui s’adapte. Une IA ne devient pas intelligente parce qu’elle produit du texte mais parce qu’elle gère ses déséquilibres, corrige ses erreurs et retrouve d’elle-même un point d’équilibre. Les modèles de langage apprennent des mots. Un système vivant apprend de lui-même.
Dans mon métier, la logique est identique. Un réseau sûr n’est pas un réseau parfait. C’est un réseau qui comprend ses failles avant qu’on ne les exploite. Intelligence et sécurité partagent la même racine : la vigilance.
Épilogue : ce que la machine m’a appris sur l’humain
Vingt ans plus tard, je reviens au point de départ. Eliza ne pensait pas mais elle m’a appris à penser la machine. Les modèles de langage s’expriment mieux qu’elle et pourtant ils ne comprennent toujours rien. La différence vient de nous et de notre besoin d’y croire.
L’IA ne remplace pas l’humain, elle le révèle. Elle met en lumière nos angles morts, nos illusions de contrôle et notre dépendance au langage. Mon travail consiste à défendre les systèmes et le sens. Avant de protéger les réseaux, il faut protéger les mots.
l’intelligence sous contrôle
L’Europe n’a pas choisi de rêver l’IA, elle a choisi de l’encadrer, et c’est une bonne chose. Le règlement IA Act définit juridiquement ce qu’est une IA et classe les usages par niveau de risque. Il impose transparence, auditabilité et traçabilité des modèles. Pour un ingénieur sécurité, le message est clair : si l’on ne comprend pas son modèle, on n’a pas le droit de l’utiliser. Le marketing autour de l’IA générative n’autorise pas l’opacité technique.
Dans la finance, DORA transforme l’IA en composant critique de la résilience opérationnelle. Le texte impose supervision, tests réguliers, redondance et gouvernance. Si le maillon IA cède, la chaîne lâche. La vigilance ne peut pas être déléguée à un algorithme sans contrôle humain effectif. NIS2 élargit le périmètre des entités essentielles et renforce la gouvernance comme la notification d’incidents. Les modèles utilisés dans ces secteurs doivent respecter les mêmes exigences d’authenticité des sources, d’explicabilité et de conformité démontrable sur toute la chaîne, y compris chez les prestataires. Sécurité et sens doivent avancer ensemble. Une IA n’est défendable que si elle est traçable, explicable et contrôlée. On ne protège que ce que l’on comprend.
Construire et sécuriser une IA générative
L’objectif est de produire du texte et de l’image de niveau professionnel, sous contrôle, traçables, exploitables en entreprise et conformes au cadre européen. Il ne s’agit pas de brandir une boîte noire, mais d’apporter des preuves et une chaîne de responsabilité lisible. Côté architecture, la voie texte repose sur un modèle autorégressif de type Transformer préentraîné sur un corpus légal et documenté, puis affiné par supervision humaine et aligné pour obtenir des réponses prévisibles et utiles. La voie image s’appuie sur un modèle de diffusion latente avec autoencodeur pour l’espace latent et un réseau de débruitage de type UNet, avant un affinage ciblé sur les domaines clients avec des techniques légères afin de limiter le surapprentissage et le vol de style. Dans les deux cas, des garde-fous sont activés : filtres de sécurité, classifieurs de sortie, règles de refus, contrôle des mentions sensibles, détection des contenus prohibés et filigrane pour la traçabilité.
Le déroulé opérationnel reste continu et vérifiable. On cadre le problème avec un cas d’usage mesurable, des métriques claires, un budget et des contraintes légales identifiées. On collecte des données à la provenance démontrable, obtenues avec consentement et sous contrat, que l’on nettoie, déduplique, désensibilise et catalogue avec un versionnage précis. On prépare les données par normalisation et filtrage, y compris la purge des informations personnelles et des contenus litigieux. On conçoit un modèle à la bonne échelle, avec un tokenizer adapté si le domaine l’exige, et une stratégie de précision et de parallélisme compatible avec les ressources. L’entraînement se fait dans un environnement reproductible avec des graines fixées, des points de contrôle signés, un suivi continu des pertes, des validations fréquentes et un journal d’expérience qui documente précisément ce qui a été fait. L’alignement et l’évaluation s’appuient sur des jeux de tests métier, des scénarios de robustesse et un red teaming qui cherche activement les limites. Le déploiement s’effectue dans un conteneur minimal signé, avec une nomenclature logicielle de type SBOM, des politiques d’exécution restreintes et une API protégée par authentification forte, quotas et journaux immuables. L’observation en production combine métriques, traces et alertes capables de détecter abus et dérives. L’amélioration continue ferme la boucle par un retour utilisateur qualifié, des réentraînements planifiés, des notes de version et une carte du modèle tenue à jour.
La sécurité se traite à chaque étape. La chaîne de données est protégée contre le poisoning par une provenance signée et des jeux canaris qui révèlent toute fuite dans les sorties du modèle. Les artefacts sont sécurisés par des constructions reproductibles, une SBOM, des signatures et des scans de dépendances, avec une isolation réseau pendant l’entraînement et un chiffrement au repos comme en transit, pilotés par une gestion de clés séparée. L’API et le runtime sont durcis par authentification forte, limites de débit, segmentation par client et gardiens de sortie capables de bloquer ou de réécrire les réponses à risque. Les attaques de type injection de prompt, notamment en contexte RAG, sont contrées par une séparation stricte du contexte système et des requêtes utilisateur, par la validation des sources citées et par un contrôle des flux sortants pour éviter l’exfiltration déguisée. La robustesse se renforce par un affinage défensif sur prompts adverses, un décodage conservateur et, lorsque c’est pertinent, un marquage des sorties.
La conformité n’est pas un vernis mais un cadre de travail. L’IA Act impose l’identification du niveau de risque, la traçabilité technique et un contrôle humain effectif. DORA exige une résilience opérationnelle crédible dans la finance, avec des tests réguliers et une gouvernance claire des tiers critiques. NIS2 renforce les mesures techniques et organisationnelles ainsi que la journalisation et la notification, y compris chez les prestataires. Un déploiement sérieux doit pouvoir produire ces preuves sans bricolage.
Avant la mise en production, la factualité et la sûreté doivent atteindre le niveau cible sur un corpus de test défini. Le modèle doit refuser correctement les demandes interdites sans nuire à l’usage légitime. Aucune fuite liée aux données d’entraînement ne doit être détectée. La SBOM et les artefacts doivent être signés. La carte du modèle, la politique d’usage, le runbook incident, les tests de charge et de panne et un plan de retrait doivent être prêts et validés.
Deux approches sont réalistes. L’option conservatrice s’appuie sur des bases ouvertes, un affinage métier et des garde-fous stricts avec des coûts contenus et une conformité plus simple. L’option ambitieuse vise un préentraînement partiel et un pipeline complet pour obtenir une différenciation forte au prix d’un effort MLOps et sécurité plus important. Dans tous les cas, on assume un arrêt net si les données ne sont pas traçables, si le cas d’usage n’est pas mesurable ou si le budget sécurité est absent.
En production, le système se traite comme un organisme. On surveille les abus, les dérives et les coûts. On mène des revues régulières de sécurité et de conformité. On maintient un red teaming continu et on planifie des réentraînements encadrés. Une IA générative devient défendable lorsque sa construction, son usage et son évolution sont explicables, vérifiables et réversibles. Le reste relève de l’apparat.
Dépendance et dérives autour des LLM
Il existe une dépendance plus subtile que la technique: la confiance. Dans les faits, une grande part des réponses générées est correcte, souvent au-delà de 80% selon les sujets. Cette réussite apparente installe un biais d’automatisation: on finit par croire la machine plus volontiers qu’un humain, parce qu’elle répond vite, proprement, sans hésiter. Le danger n’est pas l’erreur ponctuelle, c’est la perte d’esprit critique. Je refuse de déléguer le discernement. Je recoupe quand c’est nécessaire, je garde des jeux d’évaluation stables, je cite les sources quand c’est possible et je classe certains cas comme non fiables plutôt que de forcer une décision automatique. Un LLM m’accélère, il ne tranche pas à ma place.
La dépendance est aussi opérationnelle. S’appuyer sur un modèle externe, c’est accepter un maillon critique que je ne contrôle pas. Le fournisseur peut changer ses tarifs, ses limites de débit, ses conditions d’usage ou ses règles de modération du jour au lendemain. Une mise à jour peut casser un workflow en silence: mêmes prompts, sorties différentes, régression métier. À cela s’ajoutent l’indisponibilité, la latence réseau, les contraintes géographiques et les risques juridiques liés aux flux vers un tiers, aux transferts hors UE, aux droits d’entraînement et à la réutilisation des contenus.
Le marché ajoute ses propres dérives. L’engouement pousse au verrouillage: fonctionnalités propriétaires, sortie coûteuse, empreinte réelle masquée. Les tarifs montent plus vite que la valeur livrée, la facturation devient opaque, les modèles sont promus puis dépréciés en quelques mois. Les politiques d’usage changent sans concertation, les filtres se durcissent ou se relâchent au gré des pressions, et l’alignement finit par devenir un réglage éditorial que l’on subit. La dérive la plus dangereuse reste cognitive: confondre assistance et vérité. Des hallucinations bien tournées peuvent orienter des décisions si l’on renonce à un contrôle humain exigeant; à l’inverse, se reposer aveuglément sur des garde-fous automatiques produit une censure molle qui empêche d’explorer des scénarios critiques en sécurité.
Ma ligne est simple. Je traite les LLM comme des accélérateurs, pas comme des arbitres. Je construis autour d’eux une capacité défendable. Quand la factualité compte, je privilégie un RAG avec sources citées plutôt que la génération libre. Je garde une filière alternative avec des modèles ouverts, du fine-tuning léger et, si nécessaire, un hébergement souverain. Ni enthousiasme aveugle, ni rejet dogmatique: je garde le contrôle. Les LLM sont utiles et puissants, mais remplaçables. Ce qui m’importe, c’est la maîtrise durable du jugement, des données et des coûts.
Malik V.
Références
Weizenbaum, ELIZA, 1966.
Vaswani et al., Attention Is All You Need, 2017.
Kaplan et al., Scaling Laws for Neural Language Models, 2020.
NIST, AI RMF 1.0.
Ho et al., Denoising Diffusion Probabilistic Models, 2020.
Rombach et al., Latent Diffusion Models, 2022.
Bahri et al., Explaining neural scaling laws, PNAS 2024.
Christiano et al., RLHF, 2017.
Rafailov et al., DPO, 2023.
OWASP, Top 10 for LLM Applications v1.1.
Carlini et al., Extracting Training Data from LLMs, USENIX 2021.
Shokri et al., Membership Inference, CCS 2017.
Fredrikson, Jha, Ristenpart, Model Inversion, CCS 2015.
Kirchenbauer et al., Watermark for LLMs, 2023.
NTIA, Minimum Elements for an SBOM, 2021.
OWASP, CycloneDX 1.5.
SLSA 1.0.
AI Act, Règlement UE 2024-1689.
DORA, Règlement UE 2022-2554.
NIS2, Directive UE 2022-2555.