Transparence sur l'intelligence artificielle

Ce que fait l'assistant automatisé de PiloteSupport, qui en répond, ce qui lui est transmis et comment les obligations du règlement (UE) 2024/1689 sont mises en œuvre.

Dernière mise à jour : 5 septembre 2026

Le règlement (UE) 2024/1689 du 13 juin 2024 établissant des règles harmonisées concernant l'intelligence artificielle (« règlement sur l'IA ») impose des obligations de transparence proportionnées au risque du système. Le présent document expose la position de PiloteCode, Entrepreneur individuel, au capital de N/A au titre de ce règlement pour l'assistant conversationnel intégré à PiloteSupport, ainsi que les obligations qui incombent aux entreprises qui l'activent sur leur site.

1. Périmètre et classification

Le système concerné est un assistant de support conversationnel : il lit les messages d'un visiteur, recherche les passages pertinents dans la base de connaissances propre au site (documents, articles, questions-réponses fournis par l'entreprise), et rédige une réponse en langue naturelle. Selon le réglage retenu par l'entreprise, il propose une suggestion à un agent humain (mode « assistance »), répond en premier avant reprise éventuelle par un humain (mode « IA d'abord »), ou prend en charge la conversation avec transfert vers un humain à la demande (mode « IA seule »).

Le système est également utilisé, côté équipe, pour résumer une conversation, proposer des étiquettes et suggérer une réponse à l'agent.

Classification retenue : le système n'est pas un système d'IA à haut risque. Il ne relève d'aucun des domaines de l'annexe III du règlement (biométrie, infrastructures critiques, éducation, emploi, services essentiels publics ou privés, répression, migration, justice) : il ne conditionne l'accès à aucun service essentiel, n'évalue aucune solvabilité, ne participe à aucune décision d'emploi et n'est pas un composant de sécurité d'un produit. Il n'entre pas davantage dans les pratiques interdites de l'article 5 : ni manipulation subliminale, ni exploitation de vulnérabilités, ni notation sociale, ni reconnaissance des émotions, ni catégorisation biométrique. Il relève donc du seul article 50 (obligations de transparence pour certains systèmes d'IA).

Cette classification est réexaminée à chaque évolution fonctionnelle significative de l'assistant, et consignée dans la documentation interne (analyse d'impact et registre des traitements).

2. Répartition des rôles

Acteur	Rôle au sens du règlement	Ce dont il répond
Google LLC / Google Ireland Limited	Fournisseur d'un modèle d'IA à usage général (chapitre V, art. 53 et suivants) : modèle Gemini mis à disposition par API.	Documentation technique du modèle, politique d'utilisation acceptable, respect du droit d'auteur, résumé des données d'entraînement, marquage des sorties dans un format lisible par machine.
PiloteCode, Entrepreneur individuel, au capital de N/A (éditeur de PiloteSupport)	Fournisseur du système d'IA : il intègre le modèle dans un système à finalité déterminée, le met sur le marché sous son nom et définit son comportement (invites système, garde-fous, seuils).	Conception des garde-fous, mise en œuvre technique de la divulgation de l'article 50(1), conservation du marquage produit par le fournisseur du modèle, documentation mise à disposition des déployeurs, maîtrise de l'IA au sens de l'article 4 au sein de ses équipes.
Chaque entreprise cliente qui active l'assistant sur son site	Déployeur : elle utilise le système sous sa propre autorité, dans le cadre de son activité professionnelle.	Décision d'activer l'assistant et dans quel mode, contenu de la base de connaissances, exactitude des informations diffusées, information de ses visiteurs, maîtrise de l'IA de ses propres agents (art. 4), respect du RGPD en qualité de responsable de traitement.

Un déployeur qui modifierait substantiellement la finalité du système, ou qui le mettrait sur le marché sous sa propre marque, deviendrait lui-même fournisseur au sens de l'article 25 du règlement et en assumerait les obligations.

3. Obligation d'information (article 50, paragraphe 1)

L'article 50(1) impose que les personnes physiques interagissant avec un système d'IA en soient informées, de manière claire et distinguable, au plus tard lors de la première interaction, à moins que cela ne soit évident pour une personne raisonnablement avertie. PiloteSupport ne se prévaut pas de cette exception : la divulgation est systématique et ne peut pas être désactivée par le déployeur.

Dès le premier message produit par l'assistant, un encart affiche que l'interlocuteur échange avec un assistant automatisé, qu'il peut se tromper, et pour le compte de quelle entité il intervient (le nom du site est inséré dans le message).
Chaque message généré porte, dans le fil de conversation, une mention visuelle « IA » à côté du nom de l'assistant : la distinction entre un message humain et un message automatisé reste lisible à tout moment, y compris en relisant l'historique.
Le passage de l'IA à un humain, comme le retour éventuel à l'assistant, est annoncé dans le fil par un événement système (« Un membre de l'équipe va prendre le relais », « Vous n'échangez plus avec l'assistant automatisé »).
Un bouton « Parler à un humain » est proposé en permanence ; certains mots-clés (« humain », « conseiller », « agent »…) déclenchent également le transfert. La demande d'un interlocuteur humain n'est jamais refusée.
La transcription envoyée par email à la demande du visiteur conserve l'attribution de chaque message (visiteur, agent, assistant automatisé).

L'information est fournie dans la langue de la conversation, avant que la personne ne réponde au premier message de l'assistant, et reste accessible dans la notice de confidentialité du site concerné.

4. Marquage des contenus générés (article 50, paragraphe 2)

L'article 50(2) impose aux fournisseurs de systèmes générant du contenu de synthèse de marquer les sorties dans un format lisible par machine et de les rendre détectables comme générées ou manipulées artificiellement, selon des solutions techniques efficaces, interopérables, robustes et fiables dans la mesure où cela est techniquement possible.

Position retenue, exposée en toute transparence :

Marquage du fournisseur du modèle conservé en l'état. Les sorties du modèle Gemini portent le marquage SynthID appliqué par Google. PiloteSupport ne modifie, ne recompose ni ne réencode le texte produit : le marquage n'est jamais altéré par la couche applicative.
Métadonnées applicatives. Chaque message est stocké avec son auteur typé (ai) et les métadonnées du modèle utilisé. Ces informations sont reprises dans les transcriptions exportées et dans les exports de données, de sorte que la nature générée d'un contenu reste détectable en dehors de l'interface.
Limite assumée. Pour du texte court, échangé en clair dans une conversation, il n'existe pas à ce jour de solution de marquage indépendante du modèle qui soit à la fois robuste et interopérable au sens du considérant 133. Le choix retenu — conserver le marquage du fournisseur du modèle et l'accompagner de métadonnées applicatives — correspond à l'état de l'art accessible.
Calendrier. Les obligations de l'article 50 sont applicables à compter du 2 août 2026 (article 113). Le système ayant été mis sur le marché avant cette date, la mise en conformité complète est planifiée au plus tard le 2 décembre 2026, en cohérence avec le régime transitoire prévu pour les systèmes déjà en service. Cette position sera révisée à la publication du code de bonnes pratiques prévu à l'article 56 et des normes harmonisées attendues sur le marquage.

L'exception prévue à l'article 50(2) pour les systèmes qui remplissent une fonction d'assistance à l'édition standard sans modifier substantiellement les données d'entrée n'est pas revendiquée pour le mode conversationnel ; elle est en revanche pertinente pour la fonction de reformulation d'un message rédigé par un agent.

5. Maîtrise de l'IA (article 4)

L'article 4, applicable depuis le 2 février 2025, impose aux fournisseurs et aux déployeurs de garantir un niveau suffisant de maîtrise de l'IA de leur personnel, compte tenu de ses connaissances techniques, de son expérience et du contexte d'utilisation.

Une note de sensibilisation est remise à chaque membre de l'équipe et signée par lui : elle décrit ce que fait l'assistant, ses limites (risque d'erreur, absence de connaissance des faits postérieurs à sa base), l'obligation de ne jamais laisser croire qu'un message automatisé émane d'une personne, la conduite à tenir en cas de réponse erronée et les interdits (aucune inférence d'émotion, aucune donnée sensible dans les invites).
La note est reprise à chaque arrivée dans l'équipe et réexaminée à chaque évolution notable de l'assistant.
Les entreprises clientes, en qualité de déployeurs, sont invitées à reprendre cette note pour leurs propres agents ; elle leur est fournie sur simple demande à contact@pilotecode.com.

6. Garde-fous techniques

Base de connaissances propre au site : l'assistant répond à partir des contenus fournis par l'entreprise (pages, documents, articles, questions-réponses), sélectionnés par recherche sémantique et lexicale. Il n'invente pas de politique commerciale et ne consulte pas Internet.
Seuil de confiance : en dessous du seuil réglé pour le site, l'assistant ne répond pas et transfère la conversation à un humain plutôt que de risquer une réponse erronée.
Transfert systématique sur demande : bouton dédié, mots-clés de bascule, et nombre maximal d'échanges avant transfert automatique.
Budget quotidien : un plafond de consommation par site borne le nombre d'appels au modèle ; une fois atteint, les conversations sont dirigées vers l'équipe humaine.
Aucune inférence d'émotions ni catégorisation biométrique : le système ne cherche pas à déduire l'état émotionnel, l'origine, les opinions ou toute autre caractéristique protégée d'un interlocuteur, conformément à l'article 5 du règlement.
Aucune décision automatisée produisant des effets juridiques ou affectant de manière significative une personne au sens de l'article 22 du RGPD : l'assistant informe et oriente ; toute décision (remboursement, résiliation, exclusion) reste prise par une personne.
Journalisation : chaque appel au modèle est tracé (site, conversation, modèle, volumétrie, coût, latence) pour permettre le contrôle et la reconstitution des incidents, sans conserver les invites au-delà de la durée de rétention réglée pour le site.

7. Ce qui est transmis au modèle, et ce qui ne l'est pas

Transmis au modèle	Jamais transmis
Le contenu des messages de la conversation en cours (visiteur et agents). Les extraits pertinents de la base de connaissances du site. Le nom du site, la personnalité et les consignes de rédaction définies par l'entreprise. La langue de la conversation. Le nom ou l'email que le visiteur a lui-même écrits dans un message, le cas échéant.	L'identifiant de visiteur et l'identifiant de session. L'adresse IP, la localisation, le pays ou la ville. L'historique de navigation, la provenance et les paramètres de campagne. Les données de compte des membres de l'équipe. Les notes internes de l'équipe et les fiches visiteur. Tout flux de visualisation en direct ou de partage d'écran.

L'offre payante de l'API Gemini est utilisée : Google n'exploite pas ces échanges pour entraîner ses modèles. Les transferts vers les États-Unis sont encadrés par la décision d'adéquation (UE) 2023/1795 et, à titre complémentaire, par les clauses contractuelles types (décision (UE) 2021/914). Le détail figure dans la politique de confidentialité.

8. Signaler une réponse problématique

Une réponse inexacte, inappropriée ou trompeuse peut être signalée à tout moment : par le bouton d'évaluation en fin de conversation pour un visiteur, ou en écrivant à contact@pilotecode.com. Les signalements sont examinés, la base de connaissances ou les consignes sont corrigées, et les incidents significatifs sont consignés.

Questions relatives à ce document ou à la conformité du système : contact@pilotecode.com. Voir également les mentions légales, la politique de confidentialité et l'accord de traitement des données.