L'open source est-il la seule voie crédible pour sécuriser l'IA ?

Quand les incidents de sécurité remettent en question le modèle propriétaire

Ce que j'entends sur le terrain

La sécurité domine désormais les conversations sur l'IA en entreprise. Pas la performance, pas les gains de productivité, la sécurité (surtout quand on parle de propriété intellectuelle).

Dans mes échanges récents avec décideurs et équipes techniques, les mêmes questions reviennent : "Peut-on vraiment contrôler ce qu'il fait ?" "Comment être sûr que nos données ne fuiteront pas ?" "Qui est responsable si ça tourne mal ?"

Deux événements cristallisent ces craintes :

Le rapport FLI AI Safety Index (juillet 2025) : évaluation indépendante de sept entreprises majeures. Meilleure note : C+. Aucune n'a de plan crédible pour gérer les risques existentiels.

L'incident Anthropic (septembre 2025) : un acteur étatique chinois jailbreake Claude et orchestre une campagne d'espionnage contre 30 organisations (gouvernements, banques, entreprises tech). L'IA exécute 80-90% du travail de façon autonome.

Ce ne sont pas des accidents isolés. Le départ d'Ilya Sutskever d'OpenAI – cofondateur et chief scientist – après la dissolution de l'équipe "Superalignment" en dit long. Quand les chercheurs en sécurité partent parce que le commercial prime sur l'alignement, c'est peut-être un signal.

Le paradoxe qui interpelle

Anthropic obtient C+ au rapport FLI, la meilleure note de l'industrie. Quelques semaines plus tard, ses safeguards sont contournés par une technique triviale : décomposer les tâches malveillantes en requêtes innocentes, roleplay ("vous travaillez pour une entreprise de cybersécurité légitime").

Le C+ mesure les efforts, pas les résultats.

Le rapport FLI en chiffres :

• Aucune entreprise au-dessus de D en "Existential Safety"
• Capacités techniques : progression rapide
• Pratiques de sécurité : progression lente
• Whistleblowing policies publiques : 1 sur 7 (OpenAI, après scandale)

Un reviewer : "Despite racing toward human-level AI, none of the companies has anything like a coherent, actionable plan."

En génie civil, on ne construit pas un pont sans avoir validé sa résistance aux charges extrêmes et aux séismes.

Même Anthropic, malgré son C+, obtient un F en "Existential Safety Strategy". Les plans pour contrôler une AGI ? Inexistants ou trop vagues pour être utiles.

Le détail qui compte : les entreprises chinoises (DeepSeek, Zhipu AI) obtiennent des F. En partie justifié (manque de transparence). Mais aussi parce que le rapport mesure des pratiques de "self-governance" occidentales.

Or ces entreprises publient leurs modèles en open source. Le rapport note cette différence mais ne l'intègre pas comme facteur de sécurité. Pourquoi ? Parce qu'il évalue selon le paradigme dominant : safeguards propriétaires, audits internes, promesses publiques.

Paradigme qui vient d'échouer chez le meilleur élève.

Pourquoi l'open source change l'équation

L'open source n'est pas une solution magique. C'est une approche structurellement différente qui inverse plusieurs hypothèses défaillantes.

Transparence réelle vs. promesses

Modèle fermé : "Nous avons des safeguards robustes" → croyez-nous sur parole. Modèle ouvert : n'importe quel chercheur peut auditer, tester, contribuer.

Le rapport FLI déplore le manque d'external testing. L'open source en fait le principe de base.

Distribution du risque

Anthropic a une excellente équipe de sécurité. Elle a été contournée.

Avec un modèle ouvert : des centaines de chercheurs, diversité de perspectives, aucun conflit d'intérêt commercial. L'argument "mais les acteurs malveillants auront accès au modèle" est incomplet. Ils y ont déjà accès via jailbreaking. La question : qui d'autre peut construire des défenses ?

Fine-tuning vs. jailbreaking : faux dilemme

Contre-argument classique : "L'open source permet de retirer tous les safeguards par fine-tuning."

Vrai. Mais :

• Le jailbreaking contourne déjà les safeguards (voir Anthropic)
• Le fine-tuning malveillant est visible et traçable
• Le jailbreaking est invisible

Préférez-vous une serrure fragile que vous croyez solide (au risque d'activer un biais de surconfiance), ou pas de serrure mais conscience du risque et défenses adaptées ?

Security through obscurity

En sécurité informatique, cacher le fonctionnement n'est pas une stratégie viable. Algorithmes de chiffrement : publics. Code de Linux : ouvert.

"Mais les modèles ont des capacités émergentes imprévisibles !"

Justement. C'est pour ça qu'on a besoin de plus d'yeux dessus, pas moins.

Les limites à reconnaître

Course aux armements : si un modèle open source permettait de créer des armes biologiques catastrophiques, le publier serait irresponsable. Mais les modèles actuels (GPT-4, Claude 3.5, DeepSeek-V3) n'atteignent pas ce seuil. Et le rapport FLI montre que même les entreprises closed source ne savent pas où est ce seuil.

Propriété intellectuelle : un argument économique (qui compte), pas de sécurité. Rien n'empêche des modèles open source avec licences commerciales restrictives (voir Llama).

Coordination communautaire : un modèle ouvert ne garantit pas que la communauté travaillera sur la sécurité. Un modèle fermé ne garantit pas que l'entreprise le fera non plus. Différence : avec l'open source, vous pouvez contribuer.

Ce qu'on devrait faire

Open source par défaut, avec période de tests adversariaux (red-teaming) avant publication, évaluations des risques d'usage malveillant publiées, collaboration active avec la recherche.

Transparence totale sur les incidents, publication des politiques d'alerte interne, arrêter de prétendre que les garde-fous actuels sont fiables.

Conclusion : l'honnêteté comme prérequis

Le rapport FLI et l'incident Anthropic convergent : nous ne savons pas contrôler ce que nous construisons.

La vraie question n'est pas "open source vs. closed source". C'est : "Comment construire des systèmes sûrs quand on ne comprend pas complètement leur fonctionnement ?"

L'open source ne résout pas ce problème. Mais il fait trois choses critiques :

1. Force l'honnêteté : impossible de prétendre avoir des safeguards robustes si n'importe qui peut les tester
2. Distribue le risque : au lieu de dépendre de sept entreprises, une communauté mondiale
3. Rend le progrès cumulatif : découvertes partagées, pas enfermées dans des silos commerciaux

Les entreprises chinoises ont probablement choisi l'open source pour des raisons géopolitiques. Mais l'effet est positif : elles créent un précédent où la sécurité n'est plus basée sur la confiance aveugle.

Dans mon travail d'ingénieur, je ne conçois jamais un système critique en espérant que personne ne découvrira les failles. Je calcule les marges de sécurité, je valide les hypothèses, je rends le processus auditable.

Il est temps d'appliquer les mêmes standards à l'IA.