Une fenêtre de bureau restée entrouverte le soir sur un bureau de travail où un ordinateur portable est refermé à moitié

· 3 min de lecture · Mis à jour le

Vos données clients sont-elles protégées ? Trois premiers contrôles

Un écran de connexion ne suffit pas à vérifier qui peut voir vos données. Trois essais simples sur votre propre application, puis les preuves à demander à la personne qui la construit.

Votre application demande un mot de passe, mais chaque utilisateur voit-il uniquement les informations qui lui sont destinées ? Voici trois premiers contrôles à faire sur votre propre application avec des données fictives. Ils peuvent révéler un problème visible ; ils ne remplacent pas une vérification technique de la sécurité.

Comprendre ce que l’on vérifie

Se connecter permet de reconnaître une personne. Les droits d’accès décident ensuite ce qu’elle peut consulter ou modifier. Un client connecté ne doit pas obtenir les coordonnées d’un autre client simplement parce qu’il connaît l’adresse d’une page.

L’OWASP, organisation spécialisée dans la sécurité des applications, recommande de vérifier les autorisations à chaque demande, côté serveur ou dans l’infrastructure adaptée. Cacher un bouton à l’écran ne suffit donc pas : la demande elle-même doit être refusée lorsqu’elle n’est pas autorisée.

Essayer sans se connecter

Ouvrez votre application dans une fenêtre de navigation privée, sans vous connecter. Essayez les adresses de vos pages de travail habituelles. Une page publique peut être normale ; une liste confidentielle de clients ne doit pas apparaître.

Faites ce contrôle avec une version d’essai contenant des informations fictives lorsque c’est possible. Notez la page, l’action et le résultat observé. Vous aurez un exemple précis à transmettre à la personne qui entretient l’application.

Comparer deux comptes d’essai

Créez deux comptes que vous contrôlez, avec des rôles comparables. Dans chacun, ajoutez une demande fictive reconnaissable. Connectez-vous au premier compte et vérifiez qu’il ne retrouve pas la demande privée du second dans les listes ou les recherches.

Essayez également d’ouvrir l’adresse de cette demande depuis l’autre compte, si votre application utilise de telles adresses. Le résultat attendu dépend des règles choisies : un responsable peut avoir accès à plusieurs dossiers, tandis qu’un client ne voit que les siens.

Vérifier les fichiers téléchargés

Si un compte ordinaire peut exporter des données, ouvrez son fichier d’export. Il doit contenir uniquement les informations que ce compte a le droit d’obtenir. Faites aussi vérifier l’accès aux pièces jointes, car les règles ne concernent pas seulement les pages et les tableaux.

Un résultat correct sur ces essais ne prouve pas que tous les accès sont protégés. Demandez quels contrôles techniques et quels tests couvrent les autres cas. Notre guide des risques d’une application créée avec l’IA aide à préparer cette discussion.

Si vous voyez une information qui devrait être privée

Notez ce qui se passe sans diffuser ni télécharger davantage de données. Prévenez la personne responsable pour faire restreindre l’accès concerné et vérifier l’étendue du problème. Après correction, refaites l’essai qui avait échoué.

Avec Maestro, décrivez dès le départ qui peut voir et modifier chaque information, puis faites vérifier le résultat. Les étapes de validation ne constituent pas une garantie de sécurité. La page Vos données précise aussi les échanges avec les assistants pendant la construction.

Lire le guide complet : créer une application sans coder

Retour au journal

Prenez la baguette.

Laissez votre email : vous essaierez Maestro dans les premières vagues.

La beta est ouverte sur invitation sur macOS 13 et plus. Laissez votre email pour une prochaine vague d'accès. Windows est en préparation.

La beta est actuellement disponible sur macOS 13 ou plus. Votre réponse nous aide à préparer les autres versions.

Votre email ne sert qu'à vous prévenir de l'ouverture. Rien d'autre, promis.