Le problème du « qui peut voir quoi » : ajouter des permissions utilisateurs à votre appli créée avec l'IA

Le moment où votre appli créée avec l’IA cesse d’être réservée à vous seul est le moment où les permissions deviennent un vrai problème. Jusque-là, chaque page montre tout. Chaque liste montre chaque ligne. Chaque bouton fonctionne pour tout le monde. C’est une appli mono-utilisateur qui se fait passer pour multi-utilisateurs.

Puis vous ajoutez votre premier collègue, ou votre premier client, ou votre premier bêta-testeur — et il voit une chose qu’il ne devrait pas voir. Peut-être le salaire de son collègue. Peut-être un brouillon qui n’était pas prêt. Peut-être les réglages d’administration, exposés par accident.

C’est le problème du « qui peut voir quoi », et c’est la plus grosse chose que les créateurs non techniques ratent quand ils lancent un projet avec un créateur d’applis avec IA. La bonne nouvelle : vous n’avez pas besoin de devenir expert en sécurité pour le résoudre. Vous avez juste besoin d’une façon claire d’en parler à votre créateur avec IA.

Pourquoi votre appli créée avec l’IA démarre permissive

Quand vous décrivez une appli à un créateur avec IA — « je veux un CRM où je peux ajouter des clients et des notes » — le créateur optimise pour une seule chose : faire en sorte que ça fonctionne pour la personne qui décrit. L’appli par défaut est « tous ceux qui sont connectés peuvent tout voir ». C’est très bien pour un outil personnel. C’est une catastrophe dès qu’un deuxième utilisateur apparaît.

Ce n’est pas un bug du créateur d’applis avec IA. C’est le résultat naturel du fait que vous ne lui avez pas dit qui a le droit de voir quoi. Le créateur n’a aucune idée que votre liste de clients est sensible, ou que les « Notes » pourraient contenir des choses que vous ne voulez pas que les clients voient. Vous devez le lui dire.

Les trois questions à se poser avant d’ajouter un deuxième utilisateur

Avant d’inviter qui que ce soit, posez-vous trois choses. Notez les réponses — vous les transmettrez à votre créateur avec IA à l’étape suivante.

1. Quels sont les rôles ?

Pas les personnes — les catégories. La plupart des applis en ont entre deux et quatre. Pour un portail freelance : « Moi » et « Client ». Pour un outil interne : « Admin », « Manager », « Membre de l’équipe ». Pour une appli de communauté : « Modérateur », « Membre », « Invité ». Résistez à l’envie de dépasser quatre rôles trop tôt. Chaque rôle double les règles que vous devez garder à l’esprit.

2. Pour chaque rôle, que peut-il voir ?

Parcourez mentalement chaque page de votre appli. Pour chacune, demandez-vous : un Client devrait-il voir cette page tout court ? Devrait-il voir toutes les données dessus, ou seulement les siennes ? Devrait-il voir la page mais avec certains champs masqués ?

Le schéma le plus simple : les propriétaires voient tout ; tous les autres ne voient que ce à quoi on leur a explicitement donné accès. Ça fonctionne pour 80 % des applis sans beaucoup de personnalisation.

3. Pour chaque rôle, que peut-il faire ?

Même exercice, mais pour les boutons et les actions. Un Membre peut-il supprimer un projet ? Un Client peut-il modifier son profil mais pas son offre ? Un Manager peut-il inviter de nouvelles personnes ? La plupart des créateurs non techniques oublient complètement cette étape et se retrouvent avec des applis où n’importe quel utilisateur connecté peut supprimer toute la base de données d’un seul clic.

Parler de permissions à votre créateur avec IA

Une fois que vous avez les réponses, la demande à votre créateur avec IA s’écrit toute seule. Ça ressemble à ça :

Mets à jour cette appli pour gérer deux rôles : Propriétaire et Client.

Les propriétaires peuvent voir tous les clients, tous les projets et toutes les factures. Les propriétaires peuvent tout créer, modifier et supprimer.

Les clients ne peuvent voir que leurs propres projets et leurs propres factures. Ils ne peuvent pas voir la liste des clients, la page de l’équipe ni la page des réglages. Ils peuvent consulter leurs projets mais pas les modifier. Ils peuvent consulter et payer leurs propres factures.

Quand un Client est connecté, masque les liens de navigation vers Réglages et Équipe. Si un Client essaie de visiter ces pages par l’URL, redirige-le vers son tableau de bord.

Trois choses comptent dans cette demande :

Soyez précis par page et par action. « Les clients peuvent voir leurs projets » est vague. « Les clients peuvent consulter mais pas modifier leurs propres projets sur la page /projects » est quelque chose qu’un créateur avec IA peut réellement implémenter.
Dites ce qui arrive à la navigation. Masquer le lien n’équivaut pas à bloquer la page. Vous voulez les deux.
Couvrez le cas de l’URL tapée à la main. Sinon, un utilisateur curieux peut coller /admin dans sa barre de navigateur et entrer comme dans un moulin.

Les quatre erreurs que je vois chaque semaine

Après avoir observé beaucoup de créateurs lancer leur première appli multi-utilisateurs, les mêmes erreurs reviennent :

Masquer le bouton n’est pas masquer la donnée. Si vous dites à votre créateur avec IA de « masquer le bouton de suppression pour les Clients », le bouton disparaît de l’écran. Mais l’opération de suppression sous-jacente fonctionne toujours si quelqu’un trouve comment l’appeler. La solution : dites aussi au créateur de « rejeter les demandes de suppression provenant de comptes non Propriétaire côté serveur ». Si le créateur ne sait pas ce que « serveur » veut dire dans votre appli, demandez-lui de « bloquer l’action côté serveur, pas seulement de masquer le bouton ».

Un seul rôle pour deux fonctions. Les gens confondent « ceux qui paient » et « ceux qui utilisent l’appli ». Un Client qui vous paie pour un travail et un Client-employé qui utilise le tableau de bord que vous avez construit pour ce client ne sont pas le même rôle. Si vous les mélangez, vous passerez le mois suivant à rapiécer des règles au cas par cas. Deux rôles. Toujours.

Laisser les utilisateurs inviter des utilisateurs dès le premier jour. C’est tentant d’ajouter « Inviter un collègue » tout de suite. Ne le faites pas. Pour vos 10 premiers utilisateurs, invitez-les vous-même, à la main, depuis un panneau d’administration que vous seul pouvez voir. Les invitations en libre-service constituent toute une catégorie de règles de permissions (qui peut inviter qui ? quel rôle reçoivent les invités ? peuvent-ils en inviter d’autres ?). Attendez d’en avoir réellement besoin.

Faire confiance à ce que dit le créateur avec IA sans vérifier. Les créateurs avec IA vous diront, avec assurance, que les permissions sont en place. Peut-être qu’elles le sont. Peut-être pas. Testez toujours en vous connectant en tant que non-propriétaire et en essayant de faire de mauvaises choses : cliquer sur les boutons de suppression, coller des URL d’administration, modifier des champs que vous ne devriez pas pouvoir modifier. Si quoi que ce soit fonctionne alors que ça ne le devrait pas, demandez au créateur de le corriger précisément.

Une petite check-list avant d’inviter qui que ce soit

Avant d’envoyer cette première invitation à un deuxième utilisateur, parcourez ceci :

Je peux énumérer les rôles de mon appli sur les doigts d’une main.
Pour chaque rôle, je sais quelles pages il devrait voir et lesquelles il ne devrait pas.
Je me suis connecté en tant que non-propriétaire et j’ai confirmé que les mauvaises pages sont masquées.
J’ai essayé de coller une URL d’administration dans le navigateur en tant que non-propriétaire et j’ai été bloqué.
J’ai essayé de cliquer sur des boutons de suppression ou de modification qui devraient être hors de portée et j’ai été bloqué.
Si quelque chose tourne mal, j’ai un moyen de retirer rapidement l’accès d’un utilisateur.

Si l’un de ces points ne passe pas, c’est la prochaine conversation à avoir avec votre créateur avec IA — avant d’envoyer l’invitation, pas après.

Le seul changement d’état d’esprit qui aide

Construire des permissions pour une appli multi-utilisateurs revient surtout à vous imaginer en version légèrement fouineuse de votre utilisateur le plus mal élevé. Pas malveillant — juste curieux. Il cliquera sur des choses. Il collera des URL. Il essaiera de voir ce qu’il y a sur la page « Réglages » qu’il a repérée dans votre capture d’écran.

Votre travail — et celui de votre créateur avec IA — est de faire en sorte que, quand il regarde, la réponse soit cohérente : soit il peut le voir parce que c’est sa donnée, soit il ne peut pas le voir parce que ce n’est pas la sienne. Pas de bavures. Pas de pages d’administration exposées par accident. Pas de « j’avais oublié que cette page existait ».

La plupart des créateurs ne pensent aux permissions qu’au moment où quelque chose d’embarrassant arrive. La bonne nouvelle : passer 20 minutes à réfléchir aux rôles avant de lancer vous épargne les 20 heures à le corriger plus tard, plus l’e-mail que vous ne voulez pas écrire au client qui a vu ce qu’il ne fallait pas.

Vous construisez quelque chose qui a un côté multi-utilisateurs ? La prochaine fois que vous vous installez avec votre créateur d’applis avec IA, commencez la session en énumérant à voix haute les rôles de votre appli. C’est l’habitude de cinq minutes la plus facile à prendre, et elle attrapera la plupart des pires erreurs avant qu’elles n’arrivent.