🛑 Sécurité IA : ralentir la course à la superintelligence

Les risques ne se limitent pas à un scénario spectaculaire

Les inquiétudes ne portent pas uniquement sur l'idée qu'un système perdrait le contrôle. Elles touchent aussi des sujets très concrets pour les organisations et les gouvernements :

• La concentration du pouvoir entre quelques entreprises capables de financer les modèles et les infrastructures.
• Le manque de temps pour agir, si les capacités progressent plus vite que les règles et les mécanismes de supervision.
• La compétition entre États, qui peut pousser à déployer vite, avec peu de transparence.
• Les conséquences sur l'emploi, si des tâches entières sont automatisées avant que les travailleurs et les institutions puissent s'adapter.
• La difficulté à vérifier les systèmes, quand les entreprises partagent trop peu sur les données, les méthodes d'évaluation et les limites déjà connues.

Tout cela ne se traite pas avec un simple moratoire. La question du contrôle exige des travaux de sûreté. Les effets sur l'emploi supposent aussi des politiques de formation, de protection sociale et d'organisation du travail. L'intérêt de l'approche proposée est de traiter la vitesse de développement comme un facteur commun : un rythme moins brutal peut laisser plus de place pour traiter plusieurs problèmes en parallèle.

La nouveauté est surtout le passage du diagnostic à la proposition

L'AI Futures Project avait déjà été remarqué avec AI 2027, qui décrivait différentes trajectoires possibles et leurs effets. Le nouvel essai tente d'aller plus loin, en proposant des interventions coordonnées. L'idée : faire durer la montée en puissance sur de nombreuses années plutôt que de laisser tout se jouer sur une période courte et accélérée.

Pour autant, « ralentir » ne veut pas dire « arrêter l'innovation ». La proposition distingue implicitement la recherche utile, encadrée et contrôlée d'une course où les acteurs avancent sans être sûrs que les conditions de sécurité suivent. Autrement dit : on ne fait pas que modifier un calendrier, on modifie surtout les incitations et les étapes de validation.

Un dirigeant peut traduire cela en termes opérationnels assez simplement. Une mise en production rapide peut réduire le délai de mise sur le marché. Mais si le système touche des décisions sensibles, qu'il est difficile à auditer ou qu'il dépend d'un seul fournisseur, le coût de la correction après déploiement peut dépasser le gain initial. La vitesse n'est pas, en soi, une preuve de maîtrise.

Un accord international vérifiable

Le rapport appelle à un accord entre grandes puissances, notamment les États-Unis et la Chine, pour éviter une course dangereuse. L'idée est un ralentissement vérifié : les engagements ne devraient pas reposer uniquement sur des déclarations publiques, mais sur des mécanismes concrets de contrôle.

La difficulté est évidente. Un accord international doit être assez précis pour être vérifiable, sans pour autant révéler des informations qui faciliteraient le développement de systèmes à risque ou donneraient un avantage stratégique à un autre pays. Il faut aussi répondre à une question pratique : comment surveiller des capacités qui dépendent de centres de données, de puces, de logiciels et d'équipes répartis sur plusieurs juridictions ?

Un cadre qui ne couvrirait qu'une partie des acteurs pourrait simplement déplacer les activités ailleurs. À l'inverse, un accord trop large ou trop rigide risquerait de bloquer des usages utiles et de créer une bureaucratie difficile à appliquer. En pratique, la vérification et la coordination auraient probablement autant d'importance que la simple déclaration d'intention.

Plus de transparence, sans publication intégrale des modèles

Les auteurs demandent plus de transparence de la part des laboratoires, tout en excluant la publication complète des poids des modèles. Le but : permettre à des organismes indépendants de vérifier les évaluations et les procédures de sécurité, sans forcément diffuser ce qui rendrait le modèle directement réutilisable.

Ce choix reflète une difficulté déjà familière aux entreprises. Les promesses de performance se communiquent plus facilement que les conditions exactes des tests. Un score sur un jeu de références ne garantit pas que le modèle se comportera de la même manière en situation réelle, avec des documents internes, des utilisateurs sous pression et des cas qui n'ont pas été anticipés.

Une transparence réellement utile pourrait couvrir, selon le risque et l'usage :

• les méthodes et scénarios d'évaluation utilisés avant mise à disposition ;
• les limites connues et les types de tâches où le modèle échoue ;
• les mesures de sécurité et de surveillance après lancement ;
• les incidents significatifs et les corrections apportées ;
• les conditions d'accès, de conservation des données et de recours humain.

On ne peut évidemment pas tout publier, sans précaution. Mais une entreprise cliente doit pouvoir obtenir assez d'informations pour décider si le système correspond à son usage, protéger ses données et répondre de ses propres obligations.

Répartir les capacités plutôt que laisser quelques acteurs décider seuls

Le rapport plaide aussi pour que plusieurs entreprises et plusieurs pays participent au développement, plutôt que de concentrer ressources et décisions. La diversification peut réduire la dépendance à un petit nombre d'acteurs et limiter certains risques liés à une gouvernance trop centralisée.

Mais disperser ne garantit pas automatiquement la sécurité. Plusieurs laboratoires peuvent reproduire les mêmes erreurs, et multiplier les acteurs complique la coordination. La question n'est donc pas seulement « combien d'entreprises ? ». Elle porte aussi sur : quelles règles communes, quelles responsabilités, et quelle capacité de contrôle ?

Pour les entreprises européennes, ça se traduit concrètement. La dépendance à un seul fournisseur peut rester acceptable pour un outil secondaire. Elle devient plus risquée si le modèle traite des données sensibles ou s'il soutient une fonction essentielle. Prévoir un plan de repli, conserver des formats de données portables et documenter les dépendances font partie des mesures de résilience, même sans accord mondial.

Mesurer l'usage avant de l'encourager

Anthropic teste une fonction appelée Reflection, conçue pour aider les utilisateurs de Claude à examiner leur usage sur un, trois, six ou douze mois. L'outil peut faire ressortir des thèmes récurrents, des types de tâches, et proposer des plages de repos ou des rappels pour faire des pauses. C'est une version bêta, accessible à certains utilisateurs ayant activé la mémoire.

L'idée mérite l'attention des organisations : on ne pilote pas vraiment un usage si on ne sait pas à quoi il sert. Mais mesurer l'activité peut aussi révéler des habitudes personnelles. Anthropic indique d'ailleurs que certaines conversations ne sont pas incluses, et que des résumés même généraux peuvent contenir des informations sensibles.

En entreprise, la bonne question n'est donc pas seulement « combien de temps les équipes gagnent-elles ? ». Il faut aussi demander : quelles informations sont collectées, qui peut y accéder, et combien de temps elles sont conservées ? Une entreprise française ou européenne doit intégrer ces points à son analyse de conformité au RGPD et à ses règles internes de traitement des données.

Comparer les modèles autrement qu'avec un classement

SpaceXAI a présenté Grok 4.5 comme son modèle le plus avancé à ce jour, orienté vers des tâches d'ingénierie et de connaissance. L'entreprise avance de bons résultats sur certains tests, ainsi qu'un coût et une rapidité compétitifs. Mais ce type d'affirmations reste, par définition, à vérifier sur les tâches et les données de chaque client. Et au moment de l'annonce, le modèle n'était pas disponible dans l'Union européenne.

Les prix cités dans l'annonce - 2 dollars par million de jetons d'entrée et 6 dollars par million de jetons de sortie - ne suffisent pas à déterminer le coût réel. Il faut ajouter le volume de requêtes, la longueur des échanges, l'usage d'outils, les contrôles humains et le coût des erreurs. Un modèle moins cher « au tarif » peut finir plus coûteux s'il nécessite plus de vérifications ou s'il produit des résultats moins fiables pour votre cas d'usage.

Une évaluation opérationnelle devrait comparer, au minimum :

1. la qualité des résultats sur un échantillon représentatif du travail réel ;
2. le taux d'erreur et le coût de correction ;
3. la latence et la disponibilité du service ;
4. le coût total, pas seulement le prix par jeton ;
5. les conditions contractuelles, la localisation et le traitement des données ;
6. la possibilité de changer de fournisseur sans reconstruire tout le produit.

La meilleure décision n'est pas forcément de choisir « le plus performant » sur un benchmark public. C'est de choisir celui qui répond au besoin avec un risque et un coût d'exploitation acceptables.

La voix rend l'IA plus accessible, mais aussi plus présente

OpenAI a aussi annoncé une nouvelle génération de modèles vocaux pour ChatGPT, avec l'objectif de rendre les conversations plus naturelles et de mobiliser ses modèles les plus performants pour ces interactions. La voix réduit la friction : vous pouvez poser une question sans clavier, ce qui aide certains usages en mobilité et peut aussi soutenir des besoins liés au handicap.

Mais elle change aussi le contexte. Une conversation audible dans un lieu public peut exposer des informations personnelles ou professionnelles. Et une interface vocale plus fluide peut encourager des échanges plus fréquents, y compris sans que l'utilisateur ait clairement vérifié si le sujet convient à un assistant automatisé.

Pour un produit, cette évolution implique des choix assez concrets : demander une confirmation avant une action engageante, rendre la source d'une réponse visible, éviter l'enregistrement par défaut quand ce n'est pas nécessaire, et offrir un contrôle clair sur l'historique. L'expérience utilisateur ne se limite pas à rendre l'échange naturel. Elle doit aussi aider à comprendre ce que le système a « entendu » et ce qu'il va faire ensuite.

Ce que le débat ne doit pas masquer

Parler de ralentissement ne suffit pas. Il faut clarifier ce qui doit ralentir, et ce qui devrait au contraire avancer. Une recherche sur la sécurité peut améliorer les systèmes, et elle devrait être encouragée. Certaines applications apportent déjà des bénéfices immédiats en santé, en accessibilité ou en productivité. À l'inverse, la mise à l'échelle d'un modèle puissant, l'ouverture de capacités à des usages à risque, ou le déploiement sans supervision peuvent exiger des garde-fous plus stricts.

Il faut donc éviter deux raccourcis : imaginer que toute accélération serait dangereuse, ou croire que la compétition garantit automatiquement de meilleurs résultats. Le niveau de contrôle doit dépendre de la capacité du système, de son autonomie, du type de données traitées et de l'impact potentiel d'une erreur.

Dans l'Union européenne, les règles existantes (dont le règlement sur l'intelligence artificielle) constituent déjà un cadre de référence pour certains usages. Elles ne dispensent pas l'évaluation produit, ni les obligations liées aux données personnelles, à la sécurité ou au secteur concerné. En clair : une entreprise ne peut pas conclure qu'un outil est « acceptable » parce qu'il est disponible sur le marché.

Une méthode pragmatique pour les organisations

Même sans attendre un accord international, une entreprise peut éviter de confondre expérimentation et déploiement. La démarche suivante aide à décider sans bloquer les projets par principe.

1. Définir la tâche, pas la tendance. Travaillez sur un processus précis : rédaction d'un premier brouillon, recherche dans une documentation, aide au support, ou analyse de code. « Utiliser l'IA » n'est pas un objectif exploitable.
2. Classer les conséquences d'une erreur. Une suggestion interne, facilement vérifiable, n'a pas le même niveau de risque qu'une décision qui touche un client, un salarié ou un dossier financier. Identifiez qui subit l'impact et comment une erreur peut être détectée.
3. Tester sur des cas réels. Constituez un échantillon représentatif, y compris des cas limites. Comparez l'outil à votre méthode actuelle en mesurant la qualité, le temps gagné et le coût du contrôle. Un essai convaincant sur trois démonstrations ne prouve pas la robustesse du processus.
4. Encadrer les données et les responsabilités. Précisez ce qui est autorisé, les accès, les durées de conservation et les rôles de validation. Pour les usages sensibles, impliquez tôt les équipes juridiques, sécurité, métiers et protection des données avant mise en production.
5. Déployer par étapes, avec un seuil de retour arrière. Commencez avec un périmètre limité. Définissez ce qui déclenche l'élargissement, la suspension ou le remplacement. Pouvoir retirer un outil n'est pas un échec : c'est une partie normale de la gestion du risque.

Cette méthode ne « ralentit » pas tous les projets de la même façon. Elle place davantage de contrôle là où une erreur coûte cher, et laisse plus de liberté aux usages réversibles. C'est souvent plus efficace qu'une interdiction générale ou qu'un déploiement sans garde-fous.