La réponse courte
La sécurité d'un logiciel sur mesure n'est pas un ajout que vous achetez à la fin — c'est un ensemble de décisions de base intégrées dans l'architecture dès le premier jour : authentification, autorisation, validation des entrées, gestion des secrets et journalisation d'audit. Bien faire ces points bloque 90 % des attaques courantes. Les sauter et aucun patch ultérieur ne comblera entièrement la faille.
La ligne de base OWASP que toute appli sur mesure exige
L'OWASP Top 10 liste les risques de sécurité les plus courants des applications web. Pour une application B2B sur mesure, les cinq qui importent le plus : contrôle d'accès défaillant, failles cryptographiques, injections, conception non sécurisée et mauvaise configuration. Ce ne sont pas des risques théoriques — ce sont les vulnérabilités qui apparaissent dans les vrais rapports de fuite année après année.
Authentification : qui êtes-vous ?
Les mots de passe doivent être hachés, jamais stockés en clair. Utilisez bcrypt ou Argon2 avec un sel par utilisateur. Imposez une politique minimale (12+ caractères, pas de théâtre de complexité). Ajoutez l'authentification multifactorielle pour les comptes admin — ce seul point bloque la majorité des attaques par credential stuffing. Les tokens de session doivent expirer, être stockés en HttpOnly et Secure, et être invalidés à la déconnexion.
Autorisation : qu'avez-vous le droit de faire ?
Le contrôle d'accès défaillant est le risque numéro un de l'OWASP. Chaque endpoint API doit vérifier : cet utilisateur est-il connecté ? A-t-il la permission d'accéder à cette ressource spécifique ? Ne comptez pas sur le fait de cacher les boutons dans l'UI — l'API doit appliquer les permissions indépendamment. Un utilisateur ne devrait jamais pouvoir accéder aux données d'un autre en changeant un ID dans l'URL.
Protection contre l'injection : traitez toute entrée comme hostile
L'injection SQL, XSS et l'injection de commande partagent une cause racine : des données non fiables interprétées comme du code. Utilisez des requêtes paramétrées pour chaque appel base de données. Échappez tout le contenu généré par l'utilisateur avant de le rendre dans le navigateur. Ne concaténez jamais d'entrée utilisateur dans des commandes shell. Ce ne sont pas des bonnes pratiques optionnelles — c'est le minimum.
Gestion des secrets : où vivent vos clés
Les clés API, mots de passe base de données, clés de chiffrement et tokens tiers ne doivent jamais être codés en dur dans le code source. Ils doivent vivre dans des variables d'environnement ou un gestionnaire de secrets dédié (AWS Secrets Manager, HashiCorp Vault). Ils doivent être rotés régulièrement. Ils ne doivent jamais apparaître dans l'historique git — si une clé a été committée dans un repo, traitez-la comme compromise et rotatez immédiatement.
La piste d'audit que vous ne pouvez pas sauter
Journalisez chaque action significative : qui s'est connecté, ce qui a été modifié, quand, et depuis quelle IP. Ces journaux ne servent pas qu'à la conformité — c'est ainsi que vous détectez un incident après coup. Un événement de sécurité jamais journalisé est un événement jamais détecté. Stockez les journaux de manière centralisée, protégez-les contre la falsification, et conservez-les au moins 90 jours.
Erreurs de sécurité courantes dans les projets sur mesure
- Nous ajouterons la sécurité après le lancement — rattraper la sécurité coûte 3 à 5 fois plus cher que de l'intégrer dès le départ, et laisse toujours des failles.
- Compter sur l'obscurité — personne ne connaît notre appli existe n'est pas une stratégie de sécurité. Les scanners automatiques trouvent les panneaux d'admin exposés en quelques heures.
- Sauter la validation serveur — la validation côté client sert pour l'UX. Le serveur doit revalider chaque entrée, à chaque fois.
- Utiliser des dépendances obsolètes — la plupart des vraies fuites viennent de vulnérabilités connues dans des bibliothèques tierces, pas du code sur mesure. Lancez des scans de dépendances mensuellement.
- Aucun plan de réponse à incident — vous aurez un incident. La question est de savoir si vous savez quoi faire quand il arrivera.
Budget sécurité : ce que ça coûte vraiment
Pour une application B2B sur mesure, intégrer la sécurité dès le premier jour ajoute environ 15 à 25 % au coût de développement. Cela couvre les systèmes d'authentification, le middleware d'autorisation, la validation des entrées, la gestion des secrets, la journalisation d'audit et un test d'intrusion basique. Cela semble cher jusqu'à ce que vous compariez à l'alternative : une seule fuite peut coûter à une entreprise de taille moyenne de 200 000 à 500 000 $ en réponse, temps d'arrêt et frais juridiques — avant toute amende réglementaire.
Votre checklist sécurité pour le lancement
- Tous les mots de passe hachés avec bcrypt ou Argon2.
- MFA activé pour tous les comptes admin.
- HTTPS imposé partout, en-têtes HSTS configurés.
- En-têtes de sécurité configurés (CSP, X-Frame-Options, X-Content-Type-Options).
- Tous les endpoints API appliquent des contrôles d'autorisation.
- Les requêtes base de données utilisent des statements paramétrés.
- Secrets stockés en variables d'environnement, pas dans le code.
- Scan de dépendances passé sans vulnérabilité haute sévérité.
- Journal d'audit actif pour toutes les actions sensibles.
- Sauvegarde et restauration testées.
FAQ sécurité
Réponses rapides aux questions que l'on nous pose le plus souvent sur la sécurité des logiciels sur mesure.
Le logiciel sur mesure est-il plus ou moins sûr que le prêt-à-porter ?
Cela dépend entièrement de comment il est construit. Le logiciel prêt-à-porter bénéficie d'une large utilisation et d'un examen public — les vulnérabilités sont trouvées et corrigées vite. Le logiciel sur mesure est moins ciblé simplement parce qu'il est obscur, mais quand une vulnérabilité existe, aucun fournisseur ne pousse de patch. L'avantage du sur mesure : vous contrôlez l'architecture et implémentez exactement les contrôles de sécurité dont votre entreprise a besoin. Le risque : si votre développeur a sauté les bases, personne ne vient vous sauver.
Faut-il un test d'intrusion ?
Avant de traiter des données clients sensibles ou de traiter des paiements, oui. Un test d'intrusion basique pour une appli web sur mesure coûte de 3 000 à 10 000 $ et trouve typiquement 5 à 10 vulnérabilités réelles que les scanners automatiques ratent. Pour les secteurs régulés (santé, finance), ce n'est pas optionnel — c'est une exigence de conformité.
À quelle fréquence mettre à jour la sécurité ?
Trois couches : (1) scans automatiques de dépendances mensuellement ; (2) une revue sécurité après chaque release de fonctionnalité majeure ; (3) un test d'intrusion complet annuellement ou après des changements architecturaux significatifs. La sécurité n'est pas une case à cocher — c'est une pratique continue.
En savoir plus ?
Contactez-nous pour obtenir un devis gratuit.