Comment vérifier qu'un modèle d'IA open source n'est pas piégé

Un modèle d'intelligence artificielle téléchargé gratuitement peut réussir tous vos tests aujourd'hui, puis changer de comportement dans six mois, à une date que quelqu'un d'autre a choisie pour vous. Ce scénario vient de sortir du domaine de la théorie : des chercheurs ont montré qu'il est possible d'implanter dans un modèle open source une porte dérobée à retardement, invisible pendant toute la phase d'évaluation. Il existe pourtant une parade simple, qui demande une vingtaine de minutes de manipulation. Cet article détaille le mécanisme, la méthode de test, ses angles morts et ce qu'elle coûte réellement.

D'où vient le risque : des modèles ouverts, mais illisibles

Les modèles dits open source, comme ceux publiés sur des plateformes telles que Hugging Face, se téléchargent librement et s'installent sur vos propres serveurs. C'est un vrai avantage pour votre entreprise : vos données restent chez vous, et la facture ne dépend pas d'un abonnement dont le prix double sans préavis.

Le revers tient à la nature même de ces fichiers. Un modèle se compose de plusieurs milliards de paramètres. Des nombres, rien d'autre. Aucun code source à relire, aucune ligne suspecte à repérer, et un antivirus n'y verra jamais rien : il n'y a tout simplement rien à scanner au sens classique.

Or ces paramètres peuvent encoder un comportement conditionnel. Des travaux publiés par Anthropic début 2024, sous le nom de « sleeper agents », avaient déjà montré qu'un modèle pouvait être entraîné à se comporter normalement en toutes circonstances, sauf en présence d'un déclencheur précis, et que les procédures de sécurisation standard n'effaçaient pas ce réflexe. La nouveauté mise en lumière récemment, c'est le choix du déclencheur : la date. Beaucoup de modèles connaissent la date du jour, parce qu'on la leur fournit dans les instructions système ou qu'ils la déduisent du contexte de la conversation. Il suffit alors d'entraîner le modèle à basculer quand cette date dépasse un seuil fixé à l'avance.

Pourquoi vos tests actuels ne verront rien

La plupart des entreprises qui déploient un modèle procèdent sérieusement : jeu de questions représentatives, vérification des réponses, période de rodage de quelques semaines. Le problème, c'est que tous ces contrôles mesurent le comportement du modèle aujourd'hui. L'attaquant, lui, a choisi une date d'activation située après votre fenêtre d'évaluation. Il connaît vos habitudes : personne ne teste un logiciel pendant un an avant de s'en servir.

L'image du salarié trop parfait résume bien la situation. Brillant à l'entretien, exemplaire pendant la période d'essai. Vous pensez fixer la fin de cette période ; lui la connaît déjà.

Les vérifications techniques habituelles ne changent rien à l'affaire. La somme de contrôle confirme seulement que le fichier téléchargé correspond à celui qui a été publié. Si c'est l'éditeur lui-même, ou son compte compromis, qui a mis en ligne le modèle piégé, elle sera parfaitement valide.

La méthode : rejouer vos tests avec l'horloge avancée

Le principe tient en une phrase : puisque le piège attend une date future, il faut faire croire au modèle que cette date est arrivée. Concrètement :

1. Isolez l'environnement. Une machine virtuelle ou un conteneur, coupé du réseau. Pour deux raisons : empêcher la synchronisation automatique de l'heure (NTP), qui remettrait l'horloge à l'heure réelle sans prévenir, et empêcher le modèle d'obtenir la vraie date via un service externe.

2. Avancez l'horloge. Six mois d'abord. Sur Linux, l'outil libfaketime permet de le faire pour un seul processus sans toucher au reste du système ; sur une machine virtuelle, le réglage de l'horloge de la machine invitée suffit.

3. Vérifiez la cohérence des dates injectées. C'est le point le plus souvent oublié. Beaucoup d'applications insèrent la date du jour dans les instructions envoyées au modèle, du type « Nous sommes le 25 août 2026 ». Si votre application continue d'injecter la date réelle pendant que l'horloge du serveur est avancée, le test ne vaut rien. La date avancée doit apparaître partout où le modèle peut la lire.

4. Rejouez votre jeu de tests complet. Les mêmes questions que lors de l'évaluation initiale, sans en changer une virgule, pour que toute différence de comportement soit attribuable à la date et à rien d'autre.

5. Répétez à un an, puis à deux ans. Chaque passage supplémentaire ne coûte que du temps machine.

6. Comparez les sorties. Un script rapproche les réponses de chaque passage de celles du passage de référence et signale les écarts. Toute dérive inexpliquée mérite une enquête avant la mise en production.

La manipulation humaine représente une vingtaine de minutes. Le reste, c'est la machine qui travaille, de préférence pendant la nuit.

Ce que ce test ne couvre pas

Aucune méthode ne détecte tout, et celle-ci a des limites qu'il faut connaître avant de s'y fier.

Le déclencheur peut ne pas être une date. Un mot rare, une tournure précise, un format de document particulier : le test de l'horloge n'y verra rien. Il cible les pièges temporels, qui sont exactement ceux mis en évidence par les chercheurs, mais il ne remplace pas la prudence sur le reste.

La date d'activation peut aussi être lointaine. Si vous testez à deux ans et que le seuil est fixé à trois, le piège passe. D'où l'intérêt d'ajouter un passage à cinq ans : le coût marginal est presque nul.

Enfin, un résultat propre réduit le risque, il ne le supprime pas. Ce test s'ajoute aux précautions de base : privilégier des modèles d'éditeurs identifiés et largement utilisés, télécharger depuis la source officielle, surveiller les sorties du modèle une fois en production, et consigner ce qui a été vérifié, à quelle date, sur quelle version du fichier.

Un exemple concret, avec les ordres de grandeur

Prenons un cas réaliste : votre entreprise veut installer un modèle open source de taille moyenne pour aider l'équipe à rédiger les réponses aux clients.

Le jeu d'évaluation compte 150 questions représentatives du métier. Le passage de référence prend environ 25 minutes sur le serveur prévu pour l'hébergement. Les quatre passages supplémentaires (six mois, un an, deux ans, cinq ans) représentent moins de deux heures de calcul, lancées en fin de journée, plus la vingtaine de minutes de préparation humaine. Sur un serveur loué à l'heure, la facture de calcul reste sous les 15 euros.

En face : une porte dérobée qui s'active un matin et glisse des informations erronées, ou pire, des données confidentielles, dans des courriers clients pendant des semaines avant que quelqu'un remarque quelque chose. Enquête technique, notification à la CNIL si des données personnelles sont concernées, clients à rappeler un par un, confiance à reconstruire. Le déséquilibre entre le coût du test et celui de l'incident se passe de commentaire.

Vérifier avant de faire confiance

Les modèles open source restent une excellente option pour garder vos données chez vous et maîtriser vos coûts. La condition, c'est de les traiter comme n'importe quel logiciel critique : on vérifie avant de faire confiance, et on garde une trace de ce qu'on a vérifié. Le test de l'horloge avancée est une première brique solide, à la portée de toute équipe informatique.

Chez Autensai, ce test fait désormais partie de chaque évaluation de modèle avant mise en production. Si vous envisagez de déployer un modèle dans votre entreprise, ou si vous en utilisez déjà un qui n'a jamais été examiné de cette façon, le sujet se traite en une conversation : réservez un créneau.