Un logiciel sur mesure traite presque toujours des données personnelles. Un portail client connaît vos clients, un outil de planification connaît vos collaborateurs, un formulaire de demande collecte des noms, des adresses et parfois bien plus sensible encore. Et pourtant, dans la pratique, la question du RGPD ne surgit bien trop souvent qu'après la construction, quand quelqu'un se demande soudain où se trouvent réellement toutes ces données. La réparation est alors coûteuse et laborieuse, alors qu'en amont il suffisait de poser les bonnes questions.
Cet article vous aide à poser ces questions à temps. Pas un cours de droit, mais une check-list pratique pour toute personne qui veut faire créer un logiciel sur mesure conforme au RGPD et ne veut pas que la conformité devienne une mauvaise surprise après coup.
Pourquoi cela pèse davantage avec un logiciel construit par IA
Avec un logiciel construit par IA s'ajoute une couche que vous rencontrez moins vite chez une agence traditionnelle. Trois questions deviennent alors soudain très concrètes.
Où tourne le modèle d'IA qui construit ou anime votre logiciel ? Beaucoup de services d'IA connus tournent sur des serveurs hors d'Europe, et si vos données y transitent, c'est un traitement sur lequel vous devez avoir un avis. C'est ici qu'entre en scène la notion d'IA souveraine : une IA dont vous savez où elle tourne et ce qu'elle fait de vos données.
Où vos données se trouvent-elles au final ? Le logiciel construit doit tourner quelque part. Si c'est par défaut sur une infrastructure cloud américaine, vos données personnelles se retrouvent hors de l'UE sans que vous l'ayez choisi en connaissance de cause. Un logiciel hébergé dans l'UE écarte d'emblée ce doute.
Et quelqu'un s'entraîne-t-il sur vos données clients ? Certains outils utilisent les données qui les traversent pour améliorer leurs propres modèles. Pour vos données clients, c'est presque toujours indésirable, et parfois tout simplement interdit.
Ces questions ne sont pas effrayantes une fois posées, mais elles doivent l'être. C'est précisément pourquoi une approche méthodique du développement IA se doit de traiter le RGPD comme un choix de conception explicite, et non comme quelque chose que l'on réglera plus tard.
Les six points de contrôle pour un logiciel conforme au RGPD
Que vous frappiez à la porte d'une agence, d'un fournisseur SaaS ou d'une équipe de développement IA, voici les six choses que vous voulez avoir en ordre au préalable.
Localisation des données et hébergement dans l'UE
Où se trouvent physiquement vos serveurs, sauvegardes et fichiers journaux ? Pour les données personnelles, un hébergement au sein de l'UE est la route la plus simple et la plus sûre. Dès que des données partent vers des pays sans niveau de protection adéquat, il vous faut des garanties supplémentaires et cela devient inutilement compliqué. Demandez explicitement où tout tourne, sauvegardes comprises, car on les oublie souvent.
Accord de sous-traitance
Dès qu'un fournisseur traite des données personnelles pour votre compte, un accord de sous-traitance (un DPA) s'impose. Il précise ce que le fournisseur peut faire des données, comment elles sont protégées et ce qui se passe en cas de problème. Pas de DPA, c'est un trou dans votre responsabilité, et c'est un trou dont on vous tiendra rigueur.
Piste d'audit
Pouvez-vous retracer qui a consulté ou modifié quelles données et quand ? Une piste d'audit n'est pas seulement utile en cas d'incident, c'est souvent une exigence stricte pour démontrer que vous traitez les données avec soin. Demandez si elle est incluse d'office dans le logiciel ou si vous devez la prévoir à part.
Minimisation des données
Le logiciel ne collecte-t-il que ce qui est vraiment nécessaire, ou stocke-t-il de tout « au cas où » ? Le RGPD exige la minimisation des données : moins de données, c'est moins de risque, moins de maintenance et moins de choses dont vous êtes responsable. Cela commence dès la conception de vos formulaires et de votre modèle de données. Qui tient encore ses données dans des fichiers épars verra dans d'Excel à une application web comment rendre ce chaos dispersé structuré et maîtrisable.
Export et propriété du code et des données
À qui appartient le code, et à qui appartiennent les données ? Pouvez-vous à tout moment exporter et emporter vos données ? Il s'agit ici de souveraineté numérique autant que de verrouillage. Si vos données sont prisonnières du système d'un fournisseur, vous êtes dépendant, et cela heurte le principe selon lequel c'est vous qui gardez la maîtrise de vos propres données personnelles.
Sous-traitants ultérieurs et entraînement de l'IA
Quelles autres parties (sous-traitants ultérieurs) sont sollicitées, et que font-elles des données ? Et la question centrale avec l'IA : vos données sont-elles utilisées pour entraîner des modèles ? Vous voulez un non clair sur ce dernier point, noir sur blanc. Un fournisseur qui reste vague là-dessus est un fournisseur à qui vous ne confiez pas encore vos données clients.
Les bonnes questions à poser à votre fournisseur
Ces points de contrôle ne deviennent utiles qu'une fois transformés en questions concrètes. Voici comment distinguer une bonne réponse d'un signal d'alarme.
| Question à votre fournisseur | Bonne réponse | Signal d'alarme |
|---|---|---|
| Où sont mes données, sauvegardes comprises ? | « Au sein de l'UE, et nous pouvons le prouver. » | « Quelque part dans le cloud » ou pas de réponse claire |
| Puis-je obtenir un accord de sous-traitance ? | « Oui, partie standard du contrat. » | « Est-ce vraiment nécessaire ? » |
| Mes données servent-elles à entraîner l'IA ? | « Non, explicitement pas, c'est inscrit dans l'accord. » | « Uniquement pour améliorer le service » |
| Puis-je exporter mes données et mon code ? | « Oui, à tout moment, cela vous appartient. » | L'export est payant ou impossible |
| Existe-t-il une piste d'audit ? | « Oui, intégrée d'office. » | « Nous pourrions éventuellement la construire » |
| Quels sous-traitants ultérieurs utilisez-vous ? | Une liste concrète et à jour | Aucune visibilité ou pas de réponse |
Si plusieurs questions reçoivent une réponse vague, c'est déjà une information en soi. La conformité au RGPD n'est pas quelque chose qu'un fournisseur sérieux esquive.
Erreurs fréquentes
Trois pièges reviennent sans cesse dans la pratique, et ils sont tous évitables.
Des outils américains sans DPA. Déployer un service populaire sans vérifier où atterrissent les données et sans accord de sous-traitance. Tout va bien jusqu'à ce que ça tourne mal, et là vous vous retrouvez les mains vides.
« On réglera ça plus tard. » Traiter le RGPD comme une variable d'ajustement, après la construction. Plus tard signifie en pratique : reconfigurer le logiciel, migrer les données et conclure les accords après coup, à un coût bien plus élevé que si vous l'aviez pris en compte en amont.
Des données dans des outils de prototypage. Construire vite quelque chose dans un outil prompt-vers-app et y verser de vraies données clients. Les outils de prototypage sont rarement pensés pour la responsabilité RGPD, et la localisation des données y est souvent un angle mort. Parfait pour tester une idée, pas pour y héberger de vraies données personnelles.
Comment Turtleship y répond
Chez Turtleship, le RGPD n'est pas un à-côté mais un point de départ. Votre logiciel et vos données tournent par défaut au sein de l'Europe, pour que vous n'ayez pas à deviner où atterrissent les données personnelles. Un logiciel hébergé dans l'UE, en somme, avec une IA souveraine qui ne détourne pas vos données clients. Le code et les données vous appartiennent, dans votre propre dépôt, donc pas de verrouillage. Et une piste d'audit fait partie des blocs, pour que vous puissiez retracer qui a fait quoi.
Cela devient concret avec les portails que vous faites construire. Un portail client traite les données de vos clients, un portail fournisseurs celles de vos fournisseurs, et un portail collaborateurs sur mesure celles de vos propres équipes. Dans les trois cas, la question « où se trouvent ces données et qui peut y accéder » fait partie de la conception dès le départ, et non quelque chose que l'on plaque après coup. Cela vaut tout autant pour les portails clients chez les prestataires de services, où la confidentialité est souvent au cœur de la relation.
Conclusion
Un logiciel sur mesure conforme au RGPD n'est pas une affaire de chance ni d'un service juridique qui l'approuve après coup. C'est une affaire de bonnes questions posées au bon moment : en amont, pas après la construction. Où sont mes données ? Existe-t-il un accord de sous-traitance ? Entraîne-t-on des modèles sur mes données clients ? Puis-je tout exporter et emporter ?
Un fournisseur qui répond à ces questions par un oui clair vous donne plus que la seule conformité. Il vous donne la certitude de confier des données personnelles à votre logiciel l'esprit tranquille. Et cette confiance est précisément ce dont il est question pour un logiciel destiné à vos clients, vos fournisseurs et vos collaborateurs.
Vous voulez faire construire un logiciel où l'hébergement dans l'UE et la propriété des données sont le point de départ ? Commencez gratuitement et voyez comment Turtleship prend en compte le RGPD dès la première étape de construction.