L’échange sécurisé de documents
Composer une équipe selon le risque du produit, et concevoir des connecteurs qui passent l’audit de sécurité d’une DSI cliente.
- Type
- Mission client, anonymisée
- Secteur
- Logiciel, gestion documentaire
- Équipe
- 8 personnes : 3 développeurs .NET, 2 Flutter, 1 Product Owner, 2 QA
- Technique
- .NET, Flutter
- Livrables
- Plateforme web, application mobile, connecteurs métier
- Mon rôle
- Composition de l’équipe, principes de sécurité, connecteurs
Une plateforme d’échange de documents confidentiels a une particularité : sa valeur se mesure à ce qui ne lui arrive pas. Pas de fuite, pas de document envoyé à la mauvaise personne, pas d’accès oublié. Les clients ne le remarquent pas tant que tout va bien. Le jour où quelque chose arrive, ils partent.
Composer l’équipe selon le risque
Quand l’éditeur m’a demandé de constituer une équipe pour faire évoluer la plateforme, j’ai commencé par la question que je pose à chaque DSI dans ce cas : que se passe-t‑il si une évolution casse une règle d’accès ? La réponse a dicté la composition de l’équipe plus que le volume de code à écrire.
L’équipe compte huit personnes : trois développeurs .NET sur le cœur applicatif et la plateforme web, deux développeurs Flutter sur l’application iOS et Android, un Product Owner, et deux QA. Deux testeurs pour cinq développeurs, c’est un ratio élevé, et il était justifié : sur ce produit, une régression de sécurité coûte infiniment plus cher que le temps passé à la chercher.
Le web, le mobile, et les outils des clients
Le produit devait être présent partout où ses utilisateurs travaillent. Le web et le mobile partagent les mêmes règles d’accès, appliquées côté serveur et non dans chaque application. C’est un principe simple, et c’est lui qui évite qu’une faille sur le mobile contourne ce que le web protège.
Les connecteurs vers les logiciels métier des clients étaient le point le plus délicat. Chaque connecteur est une porte ouverte vers un autre système. J’ai défendu une règle : un connecteur ne reçoit que les droits nécessaires à sa fonction, et chacun de ses échanges est tracé. C’est ce qu’une DSI cliente demande lors de son évaluation de sécurité, et il vaut mieux l’avoir conçu ainsi dès le départ que de le reconstruire au premier audit.
Le Product Owner, enfin, tenait un rôle que l’on sous-estime : dire non. Sur un produit de confiance, toutes les demandes des clients ne méritent pas d’être faites, surtout celles qui affaiblissent la sécurité au nom du confort.