La sécurité n’est pas une option qu’on ajoute à la fin, ni un document qu’on range dans un tiroir. C’est une discipline de vérification continue, faite de contrôles concrets, répétés, et intégrés au quotidien du développement. Voici les vérifications que nous menons systématiquement sur les produits que nous construisons et opérons — pour qu’ils soient robustes, et pas seulement fonctionnels.
Protéger ce qu’on a d’abord recensé
On ne sécurise bien que ce qu’on a pris la peine de cartographier. La première étape consiste donc à lister la surface d’attaque : quelles pages sont publiques, quelles API sont exposées, quels formulaires acceptent des données, quelles bibliothèques tierces sont embarquées, qui dispose d’accès administrateur. Cette photographie, souvent éclairante, révèle des expositions qu’on avait oubliées.
Les dépendances : la porte d’entrée la plus fréquente
Un logiciel moderne ne s’écrit pas seul : il s’appuie sur des dizaines, parfois des centaines de bibliothèques tierces. Chacune est un point d’entrée potentiel si elle porte une faille connue. Nous vérifions donc automatiquement, dans notre chaîne CI/CD, qu’aucune dépendance vulnérable ne se glisse dans le projet — et nous les tenons à jour. C’est l’un des contrôles au meilleur rapport effort/protection qui soit.
Secrets, chiffrement et configuration
Un mot de passe, une clé d’API ou un token oublié dans le code — ou pire, dans l’historique Git — est une faille béante. Nous traquons systématiquement ces secrets et veillons à ce qu’ils soient stockés à part, jamais versionnés. Nous imposons HTTPS partout (le chiffrement des échanges) et posons les bons en-têtes de sécurité HTTP, ces réglages discrets qui réduisent fortement la surface d’attaque d’un site.
Sur ce sujet, beaucoup de bonnes pratiques relèvent d’abord de l’hygiène numérique, que nous avons détaillée dans nos articles cybersécurité des TPE-PME et comment créer un mot de passe fort.
Le moindre privilège, partout
Plus un accès est large, plus il est dangereux s’il est compromis. Nous appliquons le principe du moindre privilège : chaque personne, chaque service ne dispose que des droits strictement nécessaires à sa tâche. Sur les accès critiques, l’authentification à deux facteurs est la règle. C’est aussi ce qui rend une infrastructure cloud réellement défendable.
Une sauvegarde non testée n’existe pas
C’est sans doute notre conviction la plus forte sur le sujet : une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde, c’est un pari. Trop d’organisations découvrent le jour de l’incident que leurs sauvegardes étaient incomplètes, corrompues ou impossibles à restaurer. Nous testons donc régulièrement la restauration réelle des données — un point que nous avons développé dans tester ses sauvegardes de données régulièrement.
Documenter et savoir réagir
Enfin, nous consignons les contrôles effectués et préparons la conduite à tenir en cas d’incident : qui prévenir, quoi isoler, comment communiquer. Anticiper ces gestes à froid évite la panique et les erreurs le jour où un problème survient.
Cette méthode irrigue notre audit technique, où la sécurité tient une place centrale, et nous l’avons appliquée sur des produits exigeants — d’un SaaS juridique manipulant des contrats à des plateformes financières — comme dans nos accompagnements de 321Founded ou de Caneva. La sécurité, chez nous, n’est pas un chapitre : c’est une habitude.