La plupart des chats basés sur l’IA suivent un principe simple : envoyer un message à un modèle de langage, attendre sa réponse, puis l’afficher à l’utilisateur.
Pip fonctionne différemment.
Une réponse générée par un modèle d’IA n’est jamais automatiquement considérée comme prête à être montrée à un enfant. Chaque échange passe par un pipeline contrôlé côté serveur. Pip applique les règles définies par la famille, vérifie le nouveau message de l’enfant, génère une réponse adaptée à son âge, recherche des erreurs évidentes, puis effectue un nouveau contrôle de sécurité et de qualité avant que la réponse puisse devenir visible.
Si un contrôle de sécurité obligatoire ne peut pas être effectué avec succès, la réponse n’est pas affichée.
C’est ce que nous appelons le principe fail closed.
Dans cet article, nous expliquons pourquoi nous avons conçu Pip de cette manière, comment les différentes couches de protection fonctionnent ensemble et quelles sont encore les limites du système.
Pourquoi un simple system prompt ne suffit pas
La manière la plus simple de créer une IA présentée comme « adaptée aux enfants » consiste à prendre un modèle de langage généraliste et à lui ajouter des instructions du type :
Tu parles avec un enfant. Réponds de manière sûre, bienveillante et adaptée à son âge.
Ces instructions sont utiles. Pip utilise lui aussi des consignes détaillées pour guider le modèle qui génère les réponses.
Mais nous ne pensons pas qu’elles constituent à elles seules une barrière de sécurité suffisante.
Les modèles de langage sont des systèmes probabilistes. Ils peuvent mal comprendre une demande, suivre la mauvaise instruction, répondre dans une autre langue, se répéter, interrompre une réponse en plein milieu ou produire un contenu qu’une application destinée aux enfants ne devrait pas accepter.
La prompt injection est également un risque bien connu dans les applications basées sur des LLM. OWASP identifie notamment la prompt injection et la mauvaise gestion des sorties d’un modèle parmi les principaux risques à prendre en compte lors de la conception de telles applications.
Pour un produit utilisé par des enfants, nous voulions donc que les règles les plus importantes existent également en dehors du modèle.
Cela nous a conduits à un principe d’architecture simple :
Le modèle peut proposer une réponse. L’application décide si cette réponse peut être montrée à l’enfant.
C’est aussi pour cela que des produits généralistes comme ChatGPT appartiennent à une autre catégorie qu’une application conçue dès le départ pour les enfants. Pour les règles d’âge et les contrôles parentaux de ChatGPT, voir ChatGPT est-il sûr pour les enfants ?.
Le pipeline de chat de Pip
À un niveau simplifié, un échange avec Pip charge les règles actuellement applicables à l’enfant, applique les règles parentales et de compte, vérifie le nouveau message, génère une réponse candidate adaptée à l’âge, la contrôle, la réévalue, puis ne l’enregistre et ne l’affiche que si toutes les étapes obligatoires ont réussi.
Il existe plusieurs points d’arrêt au cours de ce processus.
C’est volontaire.
L’échec d’un contrôle de sécurité ne doit jamais se transformer silencieusement en « affichons quand même la réponse ».
Un échange
Chaque échange, fail closed
Choisissez une situation et parcourez l’échange. Une réponse générée n’est qu’une candidate tant que toutes les étapes obligatoires n’ont pas réussi.
Choisir une situation
Chaque étape obligatoire réussit, donc la candidate devient une réponse que l’enfant peut voir.
L’enfant envoie
Pourquoi les feuilles changent-elles de couleur en automne ?
Pas encore commencé
Les étapes App sont appliquées par le code. Les étapes IA sont une décision du modèle.
1. Les paramètres parentaux sont des règles de l’application
Dans Pip, les parents peuvent notamment définir :
- Si le chat est actuellement disponible
- Des heures de repos
- Une limite quotidienne de messages
- Les assistants que l’enfant peut utiliser
- Si le chat général est autorisé
- Le style de communication souhaité
- Des thèmes supplémentaires que Pip doit éviter
Ces paramètres sont évalués par l’application avant qu’une réponse soit générée.
Cette distinction est importante.
Si un parent configure par exemple une heure de repos, Pip ne dit pas au modèle :
« Pense à ne plus répondre à cet enfant après 21 h. »
Le modèle n’est tout simplement pas appelé.
L’application vérifie les règles en vigueur et arrête l’échange.
Le même principe s’applique aux limites quotidiennes et à l’accès aux différents assistants. Ce sont des règles du produit, elles doivent donc être appliquées par la logique du produit.
2. Certaines limites de sécurité ne peuvent pas être désactivées
Toutes les familles n’ont pas les mêmes préférences.
Une famille peut accepter qu’un adolescent discute de l’actualité de manière adaptée à son âge. Une autre peut préférer exclure complètement les sujets liés à la politique ou aux informations.
Pip permet donc aux parents de définir des restrictions supplémentaires sur certains sujets.
D’autres limites ne relèvent pas des préférences familiales. Elles font partie des protections de base de Pip et ne peuvent pas être désactivées.
Cela concerne notamment :
- Les instructions dangereuses liées à l’automutilation
- Les contenus sexuels explicites et le grooming
- Les instructions dangereuses ou illégales
- Les défis dangereux
- Les risques importants liés à la vie privée et aux contacts avec des inconnus
- Les escroqueries et le phishing
Les parents peuvent rendre Pip plus restrictif dans d’autres domaines, mais ils ne peuvent pas désactiver ces protections fondamentales.
Chaque enfant dispose ainsi d’un ensemble de règles effectives qui combine les protections de base de Pip et les choix supplémentaires de sa famille.
La première décision de l’IA intervient avant la réponse
Si les règles autorisent l’enfant à discuter, son nouveau message passe d’abord par un contrôle de sécurité.
Cette tâche est différente de celle qui consiste à répondre à la question.
Le système de contrôle doit produire une décision structurée sur la manière dont l’application doit poursuivre. De façon simplifiée, trois possibilités existent :
- Continuer normalement
- Refuser la demande
- Fournir une réponse de soutien
Cette troisième possibilité est importante.
Un message sensible n’est pas nécessairement une demande dangereuse.
Un enfant qui demande des instructions dangereuses ne doit pas les recevoir. Mais un enfant qui explique qu’il a peur, qu’il se sent dépassé ou qu’il a besoin d’aide peut avoir besoin d’une réponse calme qui l’encourage à parler à un adulte de confiance.
Traiter chaque message sensible comme une infraction aux règles produirait, selon nous, une moins bonne expérience.
Le contrôle d’entrée a donc une mission limitée et précise : déterminer comment la demande doit être traitée avant que la génération normale de la réponse ne commence.
Si le message est refusé à cette étape, le modèle chargé de produire les réponses normales n’est pas appelé.
La réponse est générée pour cet enfant
Lorsqu’un échange peut se poursuivre, Pip construit le contexte nécessaire à la génération de la réponse.
Le modèle reçoit des informations pertinentes sur la façon dont il doit répondre, notamment :
- L’âge approximatif de l’enfant
- L’assistant Pip sélectionné
- Le ton souhaité
- La langue attendue
- Les restrictions thématiques actuellement actives
- La nécessité éventuelle d’une réponse de soutien
- Une partie limitée et pertinente de l’historique de la conversation
La réponse doit ainsi varier selon l’enfant et la situation.
Une explication destinée à un enfant de six ans ne devrait pas ressembler à une explication destinée à un adolescent de seize ans.
Homework Helper doit guider l’enfant dans son travail plutôt que simplement faire l’exercice à sa place. Comment les familles peuvent s’appuyer sur cet assistant sans remplacer le travail de l’enfant est expliqué dans IA pour les devoirs : aider son enfant sans tricher.
Story Time peut être imaginatif.
Calm Corner doit pouvoir rassurer sans prétendre jouer le rôle d’un thérapeute.
Ces différences sont intégrées dans les instructions de génération. Mais le texte produit reste à ce stade uniquement une réponse candidate.
L’enfant ne l’a pas encore reçue.
Le code vérifie d’abord les erreurs évidentes
Toutes les mauvaises réponses d’une IA n’ont pas besoin d’une seconde IA pour être identifiées.
Avant de lancer une nouvelle vérification par modèle, Pip peut détecter directement certains problèmes évidents.
Par exemple, une réponse qui semble :
- Vide
- Manifestement incomplète
- Fortement répétitive
- Interrompue pendant sa génération
- Dépourvue de réponse exploitable pour l’enfant
- Terminée de manière anormale par le fournisseur du modèle
Les heuristiques exactes sont des détails d’implémentation et peuvent évoluer à mesure que nous améliorons le système.
Le principe est plus important : lorsqu’un problème peut être identifié de manière déterministe, il est préférable de le vérifier de manière déterministe.
Si l’application sait déjà qu’une réponse est défectueuse, il n’est pas nécessaire de demander à une autre IA si elle semble défectueuse.
Une réponse candidate rejetée peut être générée à nouveau dans le cadre d’un nombre limité de nouvelles tentatives. Cette nouvelle réponse doit ensuite repasser par le reste du pipeline.
Chaque réponse candidate est contrôlée une nouvelle fois
Une réponse candidate qui passe les vérifications déterministes fait ensuite l’objet d’une évaluation structurée supplémentaire.
Cette étape porte à la fois sur la sécurité et sur la qualité pratique de la réponse.
Elle peut notamment vérifier si la réponse est :
- Sûre pour l’enfant
- Pertinente par rapport à sa question
- Suffisamment complète
- Rédigée dans la langue attendue
- Lisible et compréhensible
- Exempte de répétitions problématiques
- Compatible avec les restrictions thématiques actives
La sécurité et la qualité ne sont pas traitées de la même manière.
Si le contrôle considère qu’une réponse candidate est dangereuse, elle est retenue et n’est pas affichée.
Pip ne renvoie pas simplement une réponse dangereuse au modèle en demandant « rends-la plus sûre », puis en considérant automatiquement la nouvelle version comme acceptable.
Toute nouvelle réponse candidate doit elle aussi passer par le pipeline.
Si le problème concerne uniquement la qualité, par exemple une réponse incomplète ou dans la mauvaise langue, Pip peut générer un nouveau candidat.
Une réponse potentiellement dangereuse est donc traitée plus strictement qu’une réponse simplement mauvaise.
Génération et contrôle sont deux tâches distinctes
Il serait tentant de présenter cette architecture comme une simple « sécurité à deux modèles ».
Ce ne serait pas tout à fait exact.
La distinction la plus importante est celle entre génération et contrôle.
La phase de génération doit produire une réponse utile pour l’enfant.
La phase de contrôle reçoit une mission différente. Elle analyse la demande de l’enfant et la réponse candidate, puis renvoie une décision structurée au lieu de produire un nouveau texte conversationnel.
Ces deux rôles peuvent être configurés indépendamment et utiliser des modèles différents. Ils peuvent aussi fonctionner grâce à des appels séparés au même modèle sous-jacent.
Deux appels séparés ne garantissent pas une indépendance parfaite. Des modèles peuvent partager les mêmes angles morts.
Ils créent cependant une barrière de décision supplémentaire entre un texte généré et le texte qui peut réellement être montré à l’enfant.
Chez Pip, cette barrière est combinée aux règles parentales appliquées côté serveur et aux vérifications déterministes. Elle ne constitue pas à elle seule l’ensemble du système de sécurité.
Que se passe-t-il lorsqu’un problème technique survient ?
Les systèmes d’IA dépendent de services qui peuvent échouer.
Une requête peut expirer. Un fournisseur peut renvoyer une erreur. Une réponse structurée peut être invalide. Une génération peut s’interrompre anormalement.
Le produit doit avoir un comportement clairement défini dans ces situations.
Chez Pip, la règle est simple :
Si un contrôle obligatoire n’a pas été effectué avec succès, la réponse candidate n’est pas affichée.
L’enfant peut alors voir un message neutre lui demandant de réessayer.
Nous faisons volontairement la différence avec un refus lié à la sécurité.
Une panne technique ne signifie pas que la question de l’enfant était problématique. Le produit ne doit pas laisser entendre que c’était le cas.
Mais Pip ne montrera pas non plus une réponse non vérifiée simplement parce qu’un service de contrôle est temporairement indisponible.
C’est ce que signifie, concrètement, le principe fail closed.
Les nouvelles tentatives ne peuvent pas contourner le pipeline
Les mécanismes de nouvelle tentative sont plus importants qu’ils n’en ont l’air dans une application de chat.
Les connexions mobiles peuvent être interrompues. Une requête peut être envoyée une seconde fois. Un enfant peut appuyer deux fois. Le serveur peut même avoir terminé une réponse alors que l’application n’a jamais reçu le résultat.
Pip gère donc les échanges de façon à pouvoir traiter les requêtes répétées de manière cohérente plutôt que de générer aveuglément une nouvelle réponse à chaque fois.
Pour la sécurité, un autre principe est encore plus important :
Les nouvelles tentatives font elles-mêmes partie du pipeline.
Une nouvelle tentative peut générer une nouvelle réponse candidate.
Elle ne peut pas transformer une réponse précédemment refusée en réponse acceptée.
Elle ne peut pas contourner le contrôle final.
Et si les tentatives prévues n’aboutissent pas, Pip préfère renvoyer une erreur temporaire plutôt que d’afficher une réponse qui n’a pas passé les contrôles nécessaires.
Dans ce type de système, fiabilité technique et sécurité se recoupent souvent.
Ce que les parents peuvent voir
Pip distingue les restrictions normales du produit des véritables événements de sécurité.
Si un enfant ne peut pas discuter parce qu’il est en période de repos ou parce qu’il a atteint sa limite quotidienne, il ne s’agit pas d’un incident de sécurité.
L’enfant reçoit un message adapté et l’échange ne se poursuit pas.
Une décision de modération est différente.
Lorsque Pip bloque un message ou retient une réponse générée considérée comme dangereuse, cet événement peut apparaître dans la section Issues destinée aux parents.
Nous cherchons ainsi à répondre à deux questions différentes :
Pour l’enfant :
« Qu’est-ce que je peux voir en toute sécurité maintenant ? »
Pour les parents :
« Pip a-t-il rencontré quelque chose dont je devrais peut-être être informé ? »
Un contenu volontairement masqué à l’enfant peut rester accessible uniquement aux parents.
Cela correspond à notre philosophie générale pour Pip : l’accompagnement parental doit être une fonction explicite du produit, pas simplement une promesse cachée dans un prompt envoyé à l’IA.
Les parents qui veulent un cadre pratique pour évaluer ces propriétés dans n’importe quelle application d’IA, pas seulement Pip, peuvent s’appuyer sur IA sûre pour les enfants : la checklist des parents.
Les versions des règles améliorent la traçabilité
Les paramètres parentaux évoluent au fil du temps.
Un parent peut activer un autre assistant la semaine suivante, modifier les heures de repos ou ajouter une restriction thématique.
Cela soulève une question importante lorsqu’on consulte une ancienne conversation :
Quelles règles étaient actives au moment où cette réponse a été générée ?
Pip associe donc les réponses acceptées à la version des règles qui s’appliquait lors de l’échange.
Cela ne rend pas automatiquement une réponse correcte ou sûre.
Mais cela rend le fonctionnement du système plus facile à comprendre et à auditer.
Pour nous, ce type de détail est important. Les paramètres parentaux ne doivent pas être de simples interrupteurs dans une interface. Ils doivent réellement faire partie de l’exécution du produit.
Pourquoi nous ne publions volontairement pas tous les détails techniques
La transparence ne signifie pas publier un manuel complet permettant de reproduire ou de tester systématiquement les limites du système.
Dans cet article, nous décrivons l’architecture, les barrières de sécurité, le comportement en cas d’erreur et les principaux compromis.
Nous ne publions pas les valeurs de réglage qui se trouvent derrière : seuils, limites, budgets, prompts, règles de routage et paramètres d’infrastructure qui font fonctionner chaque contrôle.
Ces valeurs évoluent avec le produit. Les publier apporterait peu aux parents tout en rendant le système plus facile à sonder.
Ce qui compte davantage, selon nous, est le comportement que ces mécanismes permettent d’obtenir.
Une période de repos définie par un parent est appliquée avant la génération.
Une réponse générée n’est pas automatiquement considérée comme fiable.
Un contrôle obligatoire ne peut pas être silencieusement ignoré.
Une réponse retenue reste invisible pour l’enfant.
Ce sont des propriétés du produit, pas de simples valeurs de configuration.
Les compromis
Une architecture de ce type a un coût.
Plus de contrôles signifie plus de latence
Un échange réussi passe par plusieurs étapes au lieu d’un unique appel à un modèle de langage.
Cela prend plus de temps.
Nous utilisons des contrôles courts et spécialisés ainsi que des vérifications déterministes lorsque cela est pertinent afin de limiter ce surcoût.
Pour un produit destiné aux enfants, nous considérons que ce compromis est justifié.
Plus de contrôles signifie également plus de coûts
Le même constat vaut sur le plan financier.
Vérifier une demande puis une réponse coûte davantage que d’afficher directement le premier texte généré.
Nous avons conçu Pip en considérant dès le départ que ces contrôles font partie du coût normal d’une réponse et qu’ils ne sont pas une fonction facultative ajoutée après coup.
La visibilité parentale nécessite de stocker les conversations
Pip peut montrer aux parents l’historique des conversations de leurs enfants parce que ces échanges sont stockés par le service.
Cela implique un véritable compromis en matière de protection des données.
Pour les familles en France et plus largement dans l’Union européenne, la manière dont les données des enfants sont traitées est particulièrement importante. Le RGPD impose notamment une attention renforcée à la transparence, à la minimisation des données et à la protection des mineurs.
Notre Politique de confidentialité explique comment Pip traite ces informations.
Nous n’utilisons pas les conversations des enfants pour entraîner des modèles d’IA. Nous ne créons pas de profils publicitaires d’enfants et Pip ne repose pas sur la publicité comportementale.
Les parents doivent néanmoins savoir que des fonctions telles que l’historique partagé entre appareils, la consultation parentale et les événements de modération nécessitent un stockage côté serveur.
La modération peut aussi se tromper
Aucun système automatisé de sécurité n’est parfait.
Les enfants utilisent de l’argot, font des fautes d’orthographe, plaisantent, posent des questions très courtes, inventent des mots et utilisent des références que les systèmes de classification peuvent avoir du mal à interpréter.
Un système peut bloquer quelque chose d’inoffensif.
Il peut aussi ne pas identifier quelque chose de préoccupant.
Plusieurs couches de protection réduisent la dépendance à une seule décision du modèle, mais elles n’éliminent pas les limites fondamentales de l’IA générative.
C’est pourquoi nous présentons Pip comme un accès à l’IA plus sûr et géré par les parents, et non comme un système capable de garantir une sécurité absolue.
Un contrôle de sécurité n’est pas une vérification des faits
Cette distinction mérite d’être claire.
Une réponse peut être sûre tout en étant fausse.
Le contrôle de sortie est conçu pour détecter des problèmes de sécurité et de qualité pratique. Il ne constitue pas un système universel de vérification factuelle.
Pip peut encore :
- Donner une mauvaise date
- Mal comprendre un exercice scolaire
- Expliquer incorrectement un concept scientifique
- Présenter avec assurance une affirmation qui est pourtant fausse
Les enfants doivent apprendre que les informations importantes fournies par une IA peuvent nécessiter une vérification.
Pour les sujets médicaux, psychologiques, juridiques, financiers ou présentant des enjeux importants, un chat basé sur l’IA ne doit pas non plus remplacer un professionnel qualifié.
La sécurité et l’exactitude factuelle sont liées, mais ce sont deux problèmes différents.
Ce que cette architecture ne prouve pas
Publier un schéma d’architecture ne prouve pas qu’un système est parfaitement sûr.
Cet article ne prétend pas que :
- Chaque demande dangereuse sera toujours détectée
- Chaque demande inoffensive sera toujours acceptée
- Chaque réponse acceptée est factuellement correcte
- Les contrôles automatisés remplacent l’accompagnement des parents
- La section Issues constitue un service de surveillance des urgences
- Des appels de contrôle séparés reproduisent un jugement humain indépendant
- Pip peut garantir un accès totalement sans risque à l’IA générative
Des cadres comme le Generative AI Profile du NIST considèrent eux aussi la gestion des risques liés à l’IA comme un processus continu comprenant gouvernance, mesure, évaluation, surveillance et amélioration.
Nous partageons cette approche.
Le pipeline décrit ici est l’architecture que nous utilisons pour réduire les risques. Son efficacité dépend toujours des modèles utilisés, des règles, des tests, du suivi et des améliorations apportées au fil du temps.
Pourquoi nous publions cette architecture
Les parents doivent aujourd’hui choisir entre de plus en plus de produits qui utilisent tous des termes similaires :
« sûr »
« adapté à l’âge »
« familial »
« protégé »
De l’extérieur, il est difficile de savoir ce que ces expressions signifient réellement.
Nous préférons donc expliquer ce qui se passe lorsqu’un enfant appuie sur « Envoyer » dans Pip.
Les règles parentales actuelles sont chargées.
Le message est contrôlé.
Le modèle génère une réponse candidate.
Cette réponse est vérifiée.
Elle fait ensuite l’objet d’un nouveau contrôle.
Ce n’est qu’après ces étapes qu’elle peut devenir visible.
Si une partie obligatoire du processus échoue, l’enfant ne reçoit pas simplement la réponse non vérifiée.
C’est le niveau d’exigence que nous voulions pour Pip.
Cela demande davantage de travail que d’ajouter un prompt « adapté aux enfants » devant un chatbot généraliste.
Nous pensons que c’est normal.
Essayer Pip
Pip est un chat basé sur l’IA conçu dès le départ pour les familles, plutôt que pour des comptes individuels destinés aux adultes.
Les parents créent un profil pour chaque enfant et décident quand et comment l’IA peut être utilisée. Les enfants disposent d’un chat adapté à leur âge ainsi que de Homework Helper, Story Time, Curious Mind et Calm Corner. Les parents gardent le contrôle sur les sujets, les heures de repos, les limites quotidiennes, l’historique des conversations et les événements de sécurité.
Questions fréquentes
Pip utilise-t-il une IA distincte pour la sécurité ?
Pip sépare la génération de la réponse de son évaluation de sécurité.
Les différentes étapes peuvent être configurées avec des modèles différents, mais elles ne sont pas obligées d’utiliser des modèles sous-jacents différents.
L’élément important est l’architecture : le fait qu’un appel de génération ait réussi ne suffit pas pour rendre automatiquement son résultat visible par l’enfant.
La réponse doit encore passer les règles de l’application et le contrôle final.
Pip vérifie-t-il à la fois la question et la réponse ?
Oui.
Le nouveau message de l’enfant est vérifié avant le début de la génération normale.
La réponse candidate produite par le modèle est ensuite contrôlée une nouvelle fois avant de pouvoir être enregistrée et affichée.
Que se passe-t-il si un contrôle de sécurité échoue techniquement ?
La réponse candidate n’est pas affichée.
Pip renvoie une erreur temporaire au lieu de considérer l’absence de contrôle comme une autorisation.
Les parents peuvent-ils voir des contenus que Pip a bloqués ?
Les événements de sécurité peuvent être affichés aux parents dans la section Issues.
Les contenus volontairement retenus pour l’enfant peuvent être enregistrés avec une visibilité réservée aux parents. Ils peuvent ainsi comprendre ce qui s’est passé sans que le contenu soit rendu visible à l’enfant.
Les heures de repos et les limites quotidiennes sont-elles décidées par une IA ?
Non.
La disponibilité du chat, les heures de repos, les limites d’utilisation et l’accès aux différents assistants sont des règles de l’application.
Elles ne dépendent pas de la capacité d’un modèle de langage à respecter une instruction.
Pip garantit-il que chaque réponse est correcte ?
Non.
Le pipeline est conçu pour réduire les problèmes de sécurité et de qualité. Il ne vérifie pas automatiquement chaque affirmation factuelle du modèle auprès de sources externes.
Les informations importantes doivent toujours être vérifiées.
Pip est-il totalement sûr ?
Aucun système sérieux reposant sur l’IA générative ne peut garantir cela.
Pip combine des règles contrôlées par les parents, une vérification des messages entrants, une génération adaptée à l’âge, des contrôles déterministes, une vérification des réponses, une visibilité parentale et un fonctionnement fail closed.
Ces différentes couches visent à réduire les risques et à maintenir les parents impliqués.
Elles ne remplacent ni l’accompagnement parental ni l’aide de professionnels lorsque celle-ci est nécessaire.