H-Secure
Hackathon sécurité de 5 jours, en équipe de 4 aux profils hétérogènes : 2e place sur 10 équipes. En tant que chef de projet, j'ai sécurisé un système d'information de santé fictif tout en pilotant l'équipe : répartition des tâches, arbitrage des risques et coordination sous forte contrainte de temps. Ce projet relève surtout du pilotage : il montre ma capacité à organiser une équipe et à la faire avancer, plus que mes compétences techniques.
Contexte
Hackathon KEYCE, 5 jours (20 au 24 avril 2026), commandité par Kaptalis Consult. Équipe de 4, 2e place sur 10 équipes.
Client fictif : une clinique privée, Nova-Médica. Données de santé, RGPD et HDS, tolérance zéro. Un audit préalable avait révélé deux failles critiques : un IDOR permettant à un patient de lire le dossier d'un autre en changeant l'identifiant dans l'URL, et une absence totale de segmentation réseau, la base de données étant joignable depuis partout.
Mission : reconcevoir et sécuriser le système d'information en 5 jours. Stack livrée : FastAPI/Python, PostgreSQL, Docker Compose avec 3 réseaux isolés et images distroless, Nginx TLS, authentification JWT, RBAC, chiffrement AES-256, hachage Argon2.
Le problème, de pilotage plutôt que technique
Équipe de 4 personnes, niveaux académiques mixtes (Bachelor, M1, M2), avec des écarts de maîtrise de 2 à 3 points sur les compétences du chemin critique. Le brief prévoyait 5 rôles fonctionnels pour 4 personnes.
La question n'était pas technique : comment piloter une équipe hétérogène en arbitrant entre l'exigence de livraison et la montée en compétences, sur une architecture à fort enjeu réglementaire ?
Le diagnostic
Matrice de compétences, échelle de 0 (absent) à 4 (expert), croisant chaque compétence critique avec chaque membre et le niveau requis par la mission :
| Compétence | Mercier | Backend | Frontend | Infra | Requis |
|---|---|---|---|---|---|
| Docker / segmentation réseau | 4 | 2 | 1 | 2 | 3 |
| Authentification par jetons (JWT) | 4 | 1 | 2 | 1 | 3 |
| Chiffrement (AES-256, Argon2) | 4 | 1 | 1 | 1 | 3 |
| Pentest / OWASP | 4 | 1 | 2 | 2 | 3 |
| Conformité RGPD / AIPD | 4 | 1 | 1 | 1 | 3 |
| API FastAPI / Python | 2 | 4 | 2 | 1 | 3 |
| Frontend (HTML / JS) | 1 | 2 | 4 | 1 | 2 |
Les écarts ne sont pas dispersés au hasard. Ils se concentrent exactement sur le chemin critique : sécurité, cryptographie, infrastructure. Sur le papier, l'équipe était homogène, quatre profils M1-M2. En réalité, les écarts atteignaient 2 à 3 points sur les compétences les plus critiques, et le rôle infra n'a pas pu être tenu.
Cette matrice a été construite après le projet. À J0, il n'y avait qu'une auto-évaluation déclarative. C'est la principale faiblesse méthodologique de ce diagnostic : un test pratique de 30 minutes en onboarding aurait révélé l'écart trois jours plus tôt.
L'arbitrage
J1 : affectation des rôles. J2 : détection de l'écart infra, les bases de sécurité réseau et Docker manquaient. J2 : décision d'absorber le rôle infra, trois jours restants sur un chemin critique à tolérance zéro. J3 : checkpoint public avec le jury, quatre tests de sécurité, quatre PASS.
Trois responsabilités hors périmètre initial ont été reprises : l'authentification par jetons, toute l'infrastructure Docker, et la conformité. Ce n'était pas un jugement de valeur sur les personnes. C'était un calcul de risque : l'écart détecté à J2 n'était pas rattrapable en trois jours sur un chemin critique à tolérance zéro.
Le coût créé : bus factor = 1
Le bus factor est le nombre minimal de personnes dont la disparition mettrait le projet en échec. Quatre briques critiques (sécurité applicative, cryptographie, infrastructure Docker, conformité RGPD) reposaient sur une seule personne.
Une absence ce jeudi-là et l'équipe n'aurait pas pu livrer. Ce bus factor de 1 vient de mes propres décisions, pas de l'équipe. Cible pour la suite : un bus factor supérieur ou égal à 2 sur toute compétence critique.
La vérification
Livraison conforme, validée en soutenance le 24 avril. Quatre tests de sécurité PASS, zéro FAIL au checkpoint J3. Failles IDOR corrigées, chiffrement AES-256 validé, infrastructure Docker en segmentation Zero-Trust fonctionnelle, interface avec RBAC opérationnelle, AIPD livrée. 2e place sur 10 équipes.
Rituels tenus sans exception sur 5 jours : daily de 15 minutes, Kanban Notion partagé, snapshot Drive à 17h, point client. Cinq jours, cinq snapshots, cinq dailys, zéro dérogation. Aucun blocage n'est resté non résolu plus de 24 heures.
L'évaluation : le livrable, jamais la personne
Grille de 6 critères notés de 1 à 4, appliquée à chaque membre, chef de projet inclus :
| Critère | Mercier | Backend | Frontend | Infra |
|---|---|---|---|---|
| Maîtrise technique du périmètre | 4 | 3 | 3 | 2 |
| Respect des délais et jalons | 4 | 3 | 3 | 2 |
| Qualité de la documentation | 4 | 4 | 3 | 2 |
| Collaboration et communication | 4 | 3 | 3 | 3 |
| Capacité à gérer les blocages | 4 | 3 | 2 | 2 |
| Conformité du livrable | 4 | 3 | 3 | 2 |
| Moyenne / 4 | 4,0 | 3,2 | 2,8 | 2,2 |
Deux points de posture guident cette grille. L'évaluation porte sur le livrable, pas sur la personne. Un score de 2,2 mesure l'écart entre le rôle assigné et la contribution réelle, ici deux points sur cinq critères sur six. Cela ne veut pas dire que quelqu'un est mauvais.
Je me suis appliqué cette même grille, en tant que chef de projet. Un évaluateur qui s'exclut de sa propre grille n'évalue pas, il juge. Un score de 2,2 n'est pas un verdict, plutôt le signal qu'une formation aurait dû précéder l'affectation.
Ce que je ferais autrement
Un plan de formation calibré par écart n'a pas pu être appliqué en 5 jours, mais aurait dû suivre :
- Backend (JWT et sécurité applicative limités) : formation OWASP Top 10 sur 5 jours, TP authentification par jeton, revue de code sur les endpoints sensibles. Horizon 1 mois.
- Frontend (RBAC client partiel, tests insuffisants) : atelier sécurité front (XSS, CSRF), gestion des tokens côté client, pair programming. Horizon 3 semaines.
- Infra (Docker et hardening non maîtrisés) : formation Docker avancé sur 3 jours, lab hardening conteneurs, mentorat par un pair confirmé. Horizon 2 mois.
Trois axes d'amélioration pour la prochaine équipe : remplacer la substitution par le pair programming, viser un bus factor supérieur ou égal à 2 sur les compétences critiques, et formaliser l'évaluation individuelle pour la restituer aux membres, ce qui n'a pas eu lieu dans le format hackathon.
L'arbitrage central de ces cinq jours reste valable avec le recul. Faire soi-même, le choix retenu ici, a garanti la livraison : quatre tests sur quatre validés, zéro faille critique. Mais cela laisse une équipe non développée et une forte dépendance au chef de projet. L'alternative, faire grandir l'équipe via le pair programming et des revues formatrices, aurait construit une équipe plus autonome, au prix d'un risque réel sur la livraison à court terme. Ce choix était le bon pour ces cinq jours, mais il ne tiendrait pas sur six mois.