Le « vibe coding » permet à un propriétaire non développeur de créer un outil de gestion locative en quelques semaines. C'est une vraie avancée. Mais un logiciel qui affiche les bonnes données n'est pas forcément un logiciel qui protège ces données. Voici les contrôles à faire avant de mettre un tel outil en ligne, expliqués sans jargon.
Pourquoi un outil qui fonctionne peut quand même être risqué
Une IA générative produit la réponse la plus plausible à une demande. Elle écrit du code qui marche, mais elle ne connaît ni votre métier, ni vos obligations, ni les conséquences d'une donnée visible par la mauvaise personne. Le code peut donc être correct en apparence et laisser une porte ouverte.
Les cas concrets sont rarement spectaculaires. Ce sont souvent des fonctions accessibles sans être connecté, qui renvoient une liste d'informations, ou une action qui accepte un identifiant sans vérifier à qui il appartient. Rien ne plante, rien ne s'affiche à l'écran, et pourtant la donnée circule.
La question à se poser n'est donc pas « est-ce que ça fonctionne ? » mais « qui peut lire et modifier quoi ? ». Un outil personnel sur un ordinateur fermé ne pose pas les mêmes questions qu'un site accessible à des clients, à des locataires et à des collaborateurs.
Les quatre contrôles à exiger avant la mise en ligne
1. Chaque accès doit être vérifié côté serveur
Masquer un bouton dans l'interface ne protège rien : la requête peut être envoyée directement. Chaque lecture et chaque écriture doit vérifier l'identité de l'utilisateur et son rôle au moment de l'exécution, pas seulement à l'écran.
Sur un outil multi-utilisateurs, la vérification doit aussi porter sur l'organisation : un gestionnaire de votre équipe ne doit jamais pouvoir lire les données d'un autre propriétaire, même en modifiant une adresse ou un identifiant.
2. Les données sensibles ne doivent pas sortir par des fonctions publiques
Il est fréquent qu'une fonction créée pour l'interface d'administration reste accessible sans connexion. Codes de réduction, listes de clients, coordonnées bancaires : tout ce qui est servi par une fonction publique est lisible par n'importe qui.
La règle est simple : une fonction qui renvoie des données privées doit exiger une session valide et un rôle autorisé. Les autres doivent être explicitement réservées à un usage interne.
3. Les rôles doivent être testés, pas seulement décrits
Décrire trois niveaux d'accès dans une page de paramètres ne suffit pas. Il faut tester le cas réel : se connecter avec un compte limité et vérifier ce qu'il voit, ce qu'il peut ouvrir, ce qu'il peut modifier.
- Administrateur : accès complet, y compris aux finances et aux utilisateurs.
- Gestionnaire : accès aux biens et aux agendas dont il a la charge, sans les données réservées au propriétaire.
- Équipe de ménage : agenda uniquement, en lecture, sans montants ni contrats.
Un test rapide consiste à ouvrir chaque page avec le compte le plus limité. Si une information financière apparaît, l'accès est mal cloisonné.
4. Les données personnelles doivent rester maîtrisées
Un logiciel de gestion locative contient des noms, des adresses, des coordonnées et parfois des données bancaires. Trois points méritent une réponse écrite : où sont hébergées les données, qui peut y accéder techniquement, et combien de temps elles sont conservées.
Pour un propriétaire belge, l'hébergement en Europe et une politique de conservation claire simplifient le respect du RGPD. Un sous-traitant qui stocke les données doit aussi être identifié, car c'est lui qui les traite pour votre compte.
Ce que l'IA ne fera pas à votre place
L'IA accélère la construction, elle ne porte pas la responsabilité. Le critère utile est celui du développeur Simon Willison : si votre nom est sur l'outil, vous devez pouvoir expliquer comment il fonctionne et pourquoi il est sûr.
Pour un non-développeur, cela se traduit par trois habitudes.
- Faire auditer le code par quelqu'un dont c'est le métier, au moins une fois avant l'ouverture au public.
- Documenter les rôles et les données visibles pour chacun, noir sur blanc.
- Traiter la sécurité comme un entretien régulier, pas comme une case cochée au lancement.
C'est exactement le chemin suivi sur MesBiensImmo : l'outil a été construit avec de l'IA, puis repris en revue. Des fonctions publiques ont été refermées, la réinitialisation d'un compte a été limitée à la propre organisation de l'administrateur, et chaque création de ménage vérifie désormais à qui appartient le bien concerné.
Foire aux questions
Un propriétaire non développeur peut-il vraiment sécuriser son outil ?
Il peut poser les bonnes exigences et vérifier les comportements visibles : qui voit quoi, quelles pages sont accessibles sans connexion, quelles données sortent. La revue technique du code reste le travail d'un développeur, au moins ponctuellement.
Quels sont les signes d'un cloisonnement insuffisant ?
Une page qui affiche des données d'un autre bien ou d'un autre propriétaire, une fonction qui répond sans être connecté, ou un rôle limité qui voit des montants. Chacun de ces signes justifie une vérification immédiate.
Faut-il arrêter d'utiliser l'IA pour créer un logiciel de gestion locative ?
Non. L'IA reste un accélérateur précieux pour un propriétaire qui n'a pas d'équipe technique. Elle déplace simplement l'effort : moins de temps à écrire du code, plus de temps à vérifier ce que le code fait réellement.
À retenir
Un outil de gestion locative traite des données personnelles et financières : il doit être jugé sur sa sécurité autant que sur ses fonctionnalités. Vérifiez les accès côté serveur, testez chaque rôle avec un compte limité, contrôlez ce que renvoient les fonctions publiques et sachez où sont hébergées vos données. L'IA peut construire l'outil, mais c'est vous qui le mettez en ligne.