Comment protéger les données de vos utilisateurs dans votre appli créée avec l'IA (sans équipe de sécurité)

Une coach que nous connaissons a construit une appli de suivi de clients avec un créateur d’applis avec IA en un week-end. Notes de séance, objectifs, points d’étape sur les progrès — tout ce qu’elle gardait dans un carnet, désormais consultable et organisé. Ça marchait si bien que deux coachs de son entourage ont demandé à l’utiliser aussi.

C’est là que ça lui a sauté aux yeux : elle ne gardait plus ses propres notes. Elle détenait les notes d’autres personnes sur leurs clients — détails de santé, difficultés personnelles, noms. Si ces données fuitaient, ce ne serait pas son embarras à elle. Ce serait le leur.

Vous n’avez pas besoin d’une équipe de sécurité pour gérer ça de façon responsable. Vous avez besoin de trois habitudes et de la volonté de poser quelques questions directes à votre créateur d’applis avec IA. Ce guide explique comment protéger les données des utilisateurs dans votre appli créée avec l’IA au niveau qui compte vraiment pour un petit produit.

Commencez par remarquer quelles données vous détenez réellement

La plupart des créateurs sous-estiment ça. « J’ai juste un formulaire d’inscription » veut généralement dire que vous avez :

Des adresses e-mail — de quoi spammer ou hameçonner quelqu’un.
Des noms associés à des comportements — ce qu’ils ont acheté, ce qu’ils ont écrit, quand ils se connectent.
Tout ce que vos utilisateurs tapent dans les zones de texte libre — et les gens tapent n’importe quoi dans un champ de notes : numéros de téléphone, détails médicaux, salaires, plaintes sur leur patron.

Prenez dix minutes et notez chaque information que votre appli stocke sur une personne. Pas les champs de la base de données — le sens humain. « E-mail », « quels compléments alimentaires ils prennent », « les notes que leur coach a écrites à leur sujet ». Cette liste, c’est votre surface de responsabilité. Tout le reste de cet article consiste à la rendre plus petite et plus sûre.

Habitude 1 : collectez moins

Les données les moins chères à protéger sont celles que vous n’avez jamais collectées. Avant de protéger quoi que ce soit, réduisez la liste.

Parcourez la liste que vous venez de faire et demandez-vous, pour chaque élément : est-ce que je m’en sers ? L’appli de la coach demandait la date de naissance à l’inscription parce que le modèle d’inscription du créateur d’applis avec IA l’incluait. Elle ne s’en servait nulle part. Une seule phrase à son créateur d’applis avec IA — « supprime la date de naissance de l’inscription et efface la colonne » — et une catégorie entière de données sensibles avait disparu.

Les choses que les applis collectent souvent sans jamais s’en servir : dates de naissance, numéros de téléphone, adresses postales, genre, « comment avez-vous entendu parler de nous ». Si vous ne vous en servez pas ce mois-ci, vous pourrez toujours le demander plus tard. Vous ne pouvez pas dé-fuiter.

Habitude 2 : contrôlez qui peut voir quoi

Il y a deux versions de cette question, et vous avez besoin des deux.

À l’intérieur de l’appli : un utilisateur peut-il voir les données d’un autre utilisateur ? Si votre appli a des clients et des coachs, le client A peut-il jamais voir les notes du client B ? Nous avons écrit tout un guide sur les permissions des utilisateurs dans votre appli créée avec l’IA, mais la version courte : décrivez la règle à votre créateur d’applis avec IA en langage clair (« un coach ne voit que ses propres clients ; les clients ne voient qu’eux-mêmes ») puis testez-la vous-même avec deux comptes. Connectez-vous en tant qu’un utilisateur, essayez d’atteindre les données d’un autre utilisateur en cliquant partout. Cinq minutes, deux comptes de test. Ce seul test attrape la fuite la plus courante dans les petites applis.

À l’extérieur de l’appli : qui peut voir la base de données elle-même ? C’est vous, votre plateforme de création d’applis avec IA, et toute personne avec qui vous avez partagé des identifiants. Ce qui nous amène aux questions.

Habitude 3 : posez ces cinq questions à votre créateur

Vous n’avez pas besoin de comprendre les réponses en profondeur. Vous avez besoin de poser les questions, et les réponses devraient être des oui assurés. Collez celles-ci dans votre créateur d’applis avec IA, une à la fois :

« Les mots de passe des utilisateurs sont-ils stockés sous forme hachée, ou n’importe qui peut-il les lire ? » La seule réponse acceptable contient le mot « haché ». Si votre appli stocke des mots de passe que n’importe qui peut lire, corrigez ça aujourd’hui — c’est généralement un correctif en un prompt, et la plupart des créateurs modernes le font correctement par défaut.
« La connexion à l’appli est-elle chiffrée (HTTPS) ? » Cherchez le cadenas dans votre propre navigateur. Si l’adresse de votre appli commence par https://, c’est réglé.
« Si quelqu’un récupérait le fichier de la base de données, pourrait-il lire les champs sensibles ? » Ça concerne le chiffrement au repos. La plupart des plateformes d’hébergement le gèrent automatiquement — demandez quand même et notez la réponse.
« Quels services tiers reçoivent des données d’utilisateurs ? » Outils d’e-mail, analytics, processeurs de paiement. Vous ne les supprimez pas — vous complétez votre liste, car chaque service qui détient les données de vos utilisateurs fait partie de votre surface de responsabilité.
« Y a-t-il une sauvegarde, et qui peut y accéder ? » Les sauvegardes sont des copies de vos données, et les copies doivent aussi être protégées. (Si vous n’avez pas du tout mis en place de sauvegardes, commencez ici.)

Conservez les réponses dans un document. Ce document, c’est le début de votre posture de sécurité, et vous serez content qu’il existe la première fois qu’un client — ou l’avocat d’un client — posera la question.

Quand quelqu’un dit « supprimez mes données »

Quelqu’un finira par le faire, et la loi, dans la plupart des pays (le RGPD en Europe, des règles similaires ailleurs), dit que vous devez réellement le faire. Décidez maintenant quelle sera votre réponse :

Pouvez-vous supprimer un utilisateur et tout ce qui lui est lié ? Demandez à votre créateur d’applis avec IA d’ajouter ça — « crée une action admin qui supprime un utilisateur et toutes ses données » — avant d’en avoir besoin sous la pression d’un délai.
Le fait de le supprimer dans l’appli le retire-t-il aussi de votre outil d’e-mail et de vos analytics ? Vérifiez votre liste de la question 4.
Les sauvegardes le contiendront encore un moment. C’est normal et généralement acceptable — sachez-le simplement, pour pouvoir le dire honnêtement.

Répondre à une demande de suppression en un jour parce que vous vous êtes préparé, ça fait professionnel. Galérer pendant deux semaines, ça ressemble exactement à ce que c’est.

Rédigez la page de confidentialité en langage clair

Laissez tomber les 4 000 mots de charabia juridique généré, pour l’instant. Écrivez cinq phrases honnêtes : ce que vous collectez, pourquoi, qui d’autre y touche (votre outil d’e-mail, votre processeur de paiement), combien de temps vous le conservez, et comment demander la suppression. Mettez-la sur /privacy et liez-la depuis votre page d’inscription.

Ce n’est pas un conseil juridique, et si vous manipulez des données réellement sensibles — santé, enfants, finances — dépensez l’argent d’une heure avec un avocat. Mais une page claire et honnête vaut mieux qu’une page impressionnante que personne ne peut lire, et la rédiger vous force à connaître vraiment vos propres réponses.

La barre est plus basse que vous ne le craignez, et plus haute que zéro

Vous ne vous défendez pas contre des États-nations. Vous vous défendez contre les défaillances banales et courantes : un champ de données oublié dont personne n’avait besoin, une règle de permission que personne n’a testée, une table de mots de passe que quelqu’un a oublié de hacher. Protéger les données des utilisateurs à ce niveau n’est pas une compétence de spécialiste — chacune de ces défaillances se corrige avec un prompt en langage clair et un test de cinq minutes.

La coach du début a tout fait ça en un après-midi : supprimé deux champs inutilisés, lancé le test à deux comptes (et attrapé une fuite — les clients voyaient mutuellement leurs prénoms dans un menu déroulant), posé les cinq questions, écrit sa page de confidentialité. Son appli n’avait l’air en rien différente ensuite. Mais quand son amie lui a demandé « est-ce que ce truc est sûr pour mes notes de clients ? », elle avait une vraie réponse.

Prenez l’après-midi. Vos utilisateurs vous ont confié leurs données par confiance — voilà à quoi ressemble le fait de la mériter.