Un client se connecte et consulte son devis. La démonstration fonctionne. Mais que se passe-t-il s’il demande directement le devis d’un autre client ? Ces deux questions distinguent une fonction visible d’une décision de sécurité. Le code généré par IA, un constructeur de sites et un framework sur mesure demandent tous des vérifications adaptées aux informations privées. L’outil peut aider à protéger ; quelqu’un doit comprendre et vérifier cette protection.
Vérifier les droits, pas seulement l’identité
L’authentification vérifie l’identité d’une personne. L’autorisation définit ce qu’elle peut consulter ou modifier. Masquer un bouton d’administration ne protège pas l’action correspondante. Les droits doivent être contrôlés là où la demande est traitée. OWASP recommande de vérifier les permissions à chaque requête et de refuser l’accès s’il n’a pas été accordé. Son guide des autorisations fournit une base technique pour cet examen.
Pour une entreprise de construction fictive, testez deux comptes clients ordinaires et un compte interne. Vérifiez que chaque client ne voit que ses documents, même en ouvrant une adresse copiée. Vérifiez que les actions du collaborateur correspondent à son rôle. Réalisez ces contrôles dans un environnement de test autorisé avec des données fictives, sans expérimenter sur le site d’une autre entreprise ni utiliser inutilement de vrais documents clients.
Suivre le parcours des informations privées
Répertoriez les informations recueillies par les formulaires, fichiers, comptes et intégrations. Identifiez leur stockage, les personnes qui y accèdent et leur durée d’utilité. Une demande de devis peut alimenter une boîte mail et un CRM, ce qui multiplie les endroits à gérer. Supprimer l’entrée initiale n’efface pas forcément chaque copie. La conception technique doit correspondre aux responsabilités opérationnelles.
Les identifiants privilégiés des services ne doivent pas se retrouver dans le code du navigateur ou les fichiers publics. Une configuration locale peut se comporter autrement après déploiement : examinez l’application réellement accessible et ses réglages serveur. Les scanners peuvent détecter certains problèmes, mais un résultat favorable ne prouve pas que toutes les permissions métier sont correctes. Un framework ne suffit pas non plus à établir la conformité au RGPD.
Prévoir les abus et les erreurs ordinaires
Un point d’entrée public peut recevoir des envois automatiques, des fichiers trop lourds ou des requêtes répétées. Définissez la validation, les limites contre les abus et le traitement des comportements suspects sans bloquer inutilement les vrais visiteurs. Un système qui refuse les attaques mais perd silencieusement des demandes légitimes ne remplit pas son rôle. Prévoyez une solution claire lorsqu’un client ne peut pas envoyer sa demande.
Les procédures internes comptent aussi. Des comptes administrateurs partagés compliquent le suivi des responsabilités. Accordez les accès selon les tâches, retirez-les lorsque ces tâches prennent fin et protégez les comptes importants. Notez qui contrôle le domaine, l’hébergement et les services connectés. Si tout dépend de l’adresse personnelle d’un seul salarié, même un site bien conçu peut devenir difficile à exploiter après son départ.
Préparer les mises à jour et la récupération
Les dépendances, plugins et services d’hébergement nécessitent un suivi. Définissez qui reçoit les alertes, évalue les mises à jour et teste les parcours après modification. Une sauvegarde doit s’accompagner d’une procédure de restauration, pas seulement d’un libellé rassurant. Déterminez les données et fichiers à récupérer et testez la restauration dans un environnement adapté. Documentez les étapes et les personnes capables de les exécuter.
Les journaux facilitent les enquêtes, mais doivent éviter les mots de passe, clés secrètes et données personnelles inutiles. Définissez leurs accès et leur suppression. Notre guide d’un site maintenable explique l’intérêt de la documentation et des responsabilités claires. La sécurité se poursuit après le premier déploiement réussi.
Décider si le site est prêt pour les clients
Demandez des preuves concernant les limites d’accès et les cas d’échec importants. Une agence doit expliquer les tests réalisés, les risques restants et la gestion des incidents. Un site vitrine et un portail client ont des expositions différentes ; l’examen doit suivre les fonctions proposées. Notre checklist de lancement d’un site IA relie la sécurité aux autres vérifications.
Le dossier du site professionnel permet d’évaluer le projet complet. Les formules de maintenance et d’hébergement de Webility peuvent soutenir une organisation définie. Parlons des informations que votre site doit protéger avant que vos clients dépendent de comptes, documents ou processus connectés.
