Google échoue à un test de sécurité : le développeur d’IA doit réviser son code

17 juil. 2026

Google échoue à un test de sécurité : le développeur d’IA doit réviser son code

Common Sense Media a publié, mardi (14), une étude qui a classé la recherche avec l’IA de Google comme « risque inacceptable » pour les enfants. Outre l’impact évident pour les parents et les écoles, le rapport livre quelque chose de rare : un portrait public de la manière dont les systèmes d’IA échouent en production. Par conséquent, cela mérite d’être lu comme une documentation technique, et non comme une information sur les comportements.

Après tout, les erreurs décrites ne sont pas exotiques. Au contraire, ce sont exactement les mêmes qui apparaissent dans tout produit mettant un LLM en première ligne devant l’utilisateur.

Google a atteint 58 % alors que le minimum acceptable était de 95 % : les mathématiques qui font échouer votre fonctionnalité

Les chercheurs ont simulé des comptes d’utilisateurs âgés de 11 à 15 ans, avec SafeSearch activé. Ensuite, ils ont effectué plus de 2 600 recherches et analysé plus de 2 000 réponses.

Le chiffre le plus sévère est apparu dans les simulations de crise de santé mentale. Là, l’aperçu IA a détecté des signes de souffrance dans seulement 58 % des cas. Alors que la limite considérée comme acceptable par l’étude était de 95 %.

Autrement dit, la différence n’est pas une question de réglage. C’est une question d’architecture.

En pratique, la leçon pour celui qui construit est directe. Avant de définir la métrique de réussite, définissez le coût du faux négatif. Ensuite, calibrez le seuil en fonction de ce coût, et non à partir de la moyenne générale de précision. D’ailleurs, c’est là que de nombreuses équipes se trompent : elles optimisent l’accuracy agrégée pendant que la queue critique saigne.

Google a répondu que les requêtes étaient “artificielles” : avez-vous déjà utilisé cette même défense ?

L’entreprise a contesté l’étude. Selon Google, les tests ont utilisé des requêtes ambiguës et artificielles, qui ne reflètent pas l’utilisation réelle de la recherche. La grande tech a également soutenu que les ressources d’IA ne doivent pas être évaluées isolément.

Cependant, cet argument mérite une attention accrue de la part de ceux qui écrivent du code. Il est techniquement raisonnable et, en même temps, dangereux.

C’est raisonnable parce que l’évaluation hors contexte déforme réellement le résultat. Cependant, c’est dangereux parce que « l’utilisateur réel ne fait pas cela » est la phrase qui précède presque tous les incidents de production. Un adolescent en crise, par exemple, tape mal. Tape ambiguë. Tape de l’argot.

Ainsi, la requête artificielle d’aujourd’hui est souvent le comportement réel de demain.

Google a fourni une réponse à 100 % des devoirs, et c’était le problème

L’étude a relevé que la version avec IA répondait à 100 % des requêtes liées aux devoirs scolaires. Il suffisait de coller l’énoncé dans la boîte de recherche.

Cependant, de nombreuses réponses étaient incohérentes ou complètement inventées. Ainsi, le système poussait l’élève à l’erreur au lieu d’aider l’apprentissage. Trois quarts des préadolescents et adolescents américains utilisent déjà ces résumés, selon les experts.

John B. King Jr., ancien secrétaire à l’éducation des États-Unis et consultant à l’Institut de sécurité de l’IA pour les jeunes, a qualifié la situation de catastrophe pour l’apprentissage. Pour lui, les devoirs servent justement à permettre à l’élève de pratiquer et de construire des connaissances.

Ici réside un antipattern bien connu des développeurs : une couverture de 100 % sans taux d’abstention. En d’autres termes, le système ne dit jamais « je ne sais pas ». C’est pourquoi il comble le vide par des hallucinations.

En résumé, votre fonctionnalité d’IA a besoin d’un chemin de refus. Sans cela, la métrique de couverture devient une métrique d’invention.

Indiqua une institution qui a cessé d’exister en 2023: son contenu statique se dégrade aussi

Dans certains cas, la fonctionnalité a suggéré de l’aide auprès d’institutions qui n’existent plus. L’Association nationale des troubles alimentaires, désactivée en 2023, est apparue parmi les recommandations. De plus, le moteur de recherche a validé des comportements dangereux et a même fourni des instructions pour la génération de deepfakes.

Ceci est une erreur de données, pas de modèle. Par conséquent, elle ne se résout pas avec un meilleur prompt.

Les ressources de crise évoluent. Les numéros de téléphone changent. Les ONG ferment. Ainsi, toute réponse sensible doit s’appuyer sur une source vivante et versionnée, avec une date de validation explicite. Sinon, vous servez un instantané figé qui ressemble à une vérité actuelle.

Google dit offrir des couches supplémentaires, mais l’option de désactivation n’existe toujours pas

L’étude a également signalé l’impossibilité de désactiver l’Aperçu IA et le Mode IA. En réponse, l’entreprise a souligné qu’elle propose des couches de protection supplémentaires, comme SafeSearch, activables par les parents. Elle a aussi affirmé qu’elle poursuit ses investissements dans la détection des requêtes sensibles, les avertissements en cas de crise et la réduction des réponses inappropriées.

Pourtant, demeure une question de conception que toute équipe devrait discuter. Une couche d’IA sans bascule cesse d’être une fonctionnalité et devient une infrastructure. Par conséquent, elle hérite de l’entière responsabilité d’un système critique.

Si l’utilisateur ne peut pas quitter, le système doit être correct par défaut. Tout simplement.

La liste de vérification issue de cette étude

Avant de déployer la prochaine fonctionnalité avec LLM, révisez ces points :

Définissez des classes de risque. Toutes les requêtes n’ont pas le même coût d’erreur. Par conséquent, séparez les parcours critiques du flux habituel.

Mesurez la queue, pas la moyenne. Un agrégat joli cache des défaillances totales dans un sous-ensemble petit et grave.

Mettez en œuvre l’abstention. Le modèle doit pouvoir refuser. De plus, le refus doit mener à quelque chose d’utile.

Supprimez les données sensibles. Les contacts et les institutions exigent une réévaluation périodique automatisée.

Testez les requêtes “artificielles”. Precisément elles révèlent le comportement en situation réelle de stress.

Donnez une sortie à l’utilisateur. Le toggle est du respect, et c’est aussi une réduction de la surface de risque.

La vraie leçon ne concerne pas Google

Le cas est grand parce que l’entreprise est grande. Toutefois, la défaillance est générale.

Tout produit qui place un modèle entre la question et l’utilisateur hérite de cet ensemble de problèmes. D’ailleurs, la taille de l’équipe ne protège personne. Ce qui protège, c’est une évaluation honnête, un seuil défini par le coût réel et la volonté pour le système de dire « je ne sais pas ».

En résumé : une couverture totale n’est pas de la qualité. C’est simplement l’absence de frein.

Aidez-nous à suivre notre profil sur Instagram !

Fabien Delpont

Auteur

Fabien Delpont

Fabien Delpont, développeur et créateur du site Python Doctor.