Il faut séparer deux moments que le mot « données » mélange. Pendant la génération, ce que vous ÉCRIVEZ — votre description, et le texte des fichiers que vous joignez — est transmis à un fournisseur de modèles pour produire la spécification et le code ; les fournisseurs sont nommés dans la politique de confidentialité. Après, quand l'application tourne, plus rien ne part : le code livré ne contient aucun client d'intelligence artificielle dans ses dépendances, et le fichier de configuration déposé sur le serveur ne porte aucune clé d'API. Autrement dit, vos clients, vos interventions, vos adhérents — tout ce que vous saisirez ensuite — ne peuvent structurellement pas atteindre un modèle. La seule matière qui sorte est celle que vous avez rédigée pour décrire votre besoin.
Ce qui part vers un modèle, et quand
La génération a besoin de comprendre votre métier : c'est votre description qui le lui dit, et elle est donc transmise à un fournisseur de modèles, avec le texte des pièces jointes que vous ajoutez. La politique de confidentialité les nomme — Anthropic, OpenAI, xAI et Google — et précise que ces traitements peuvent avoir lieu hors de l'Union européenne, encadrés par les clauses contractuelles types de la Commission européenne. Ce n'est pas un détail à lire entre les lignes : c'est la matière première de la génération, et il n'y a pas de version du produit où votre description resterait chez vous tout en produisant une application qui vous ressemble.
Ce transfert a une fin. Il a lieu pendant la génération, pour produire la spécification puis le code, et il ne se rejoue qu'à la génération suivante — quand vous relancez, quand vous demandez une modification. Entre deux, il ne se passe rien. Il n'y a ni synchronisation continue, ni remontée d'usage vers un modèle, ni analyse en tâche de fond de ce que contient votre application.
Ce qui n'y va jamais : les données que vous saisirez ensuite
L'application déployée est un logiciel ordinaire, et c'est vérifiable en trois endroits du code livré. Sa liste de dépendances ne contient aucun client d'intelligence artificielle — que du Next.js, du React, du Prisma et des bibliothèques d'affichage. Le fichier de configuration écrit sur le serveur au déploiement tient en quatre lignes : l'adresse de la base de données, deux secrets techniques et un numéro de build ; aucune clé d'API n'y figure. Et les chiffres de votre tableau de bord sont calculés par des requêtes déterministes sur votre base, jamais par un modèle à qui l'on demanderait de lire vos lignes.
La conséquence est celle qui compte pour la question qui inquiète le plus — celle de l'entraînement des modèles. Même en se plaçant dans l'hypothèse la plus défavorable, la matière concernée ne pourrait être que votre description initiale : la phrase où vous expliquez que vous gérez un atelier, des interventions et des clients. Jamais le contenu de vos fiches clients, l'historique de vos interventions ou la liste de vos adhérents, puisque ces lignes n'ont, à aucun moment, de chemin vers un modèle.
Les pièces jointes : deux chemins, un seul passe par un modèle
Un fichier joint ne suit pas toujours la même route, et la distinction est nette dans le code. Un tableur, un CSV, un PDF ou un fichier texte sont lus SUR LE SERVEUR, par des extracteurs classiques : aucun modèle ne regarde le fichier lui-même. Une photo ou une capture d'écran, en revanche, est bel et bien envoyée à un modèle de vision, dont le rôle est précisément de la décrire — c'est la seule façon de deviner un formulaire papier ou un tableau photographié.
Il reste un point à dire franchement, parce qu'il change une décision pratique : le texte extrait d'un fichier, lui, rejoint le contexte envoyé au modèle, dans la limite de douze mille caractères par fichier. Un tableur joint pour montrer votre structure de données part donc, en tant que texte, avec votre description. Si ce fichier contient de vraies données personnelles, la bonne pratique tient en une phrase : joignez la ligne d'en-têtes et quelques lignes d'exemple anonymisées. Le générateur a besoin de la FORME de vos colonnes, pas du nom de vos clients.
Ce qui est garanti, et ce qui ne l'est pas
Une garantie concrète, d'abord, et elle est écrite dans le code : quand vous joignez un CSV pour démarrer avec vos vraies lignes, ces lignes sont placées dans votre base par un rapprochement déterministe — détection du séparateur, correspondance entre vos en-têtes et les champs, conversion typée — et aucun modèle n'intervient dans cette étape. La raison est dite noir sur blanc à cet endroit du code : les données de l'utilisateur ne se réinventent pas. Un modèle qui « compléterait » un tableau d'adhérents produirait des lignes plausibles et fausses, ce qui est le seul résultat réellement inacceptable.
Ce que cette page ne prétend pas garantir, ensuite : la politique interne de chaque fournisseur de modèles quant à la réutilisation de ce qui leur est transmis. Cela relève de leurs engagements contractuels, pas du comportement de ce produit ; la politique de confidentialité les nomme et décrit l'encadrement des transferts, et c'est là qu'il faut aller regarder. Ce que le produit garantit, lui, est le PÉRIMÈTRE — quoi sort, quand, et surtout ce qui ne sort jamais. C'est précisément parce que ce périmètre est étroit que la question de l'entraînement ne porte pas sur votre fichier clients.