Le tableau
Une banque régionale doit migrer son appli de gestion des crédits. L’appli est utilisée tous les jours par 400 conseillers dans 80 agences. Elle traite 2 000 dossiers de crédit par semaine. C’est du critique — si ça plante, les agences ne peuvent plus travailler.
La migration est imposée par la fin de support de l’ancienne plateforme. La date, c’est l’éditeur qui la fixe. Non négociable.
Le problème (spoiler : c’est pas technique)
Le projet implique 15 parties prenantes : l’éditeur, l’hébergeur, l’infra, l’équipe applicative, la MOA, le métier, la conformité, la sécurité SI… Chacun a ses contraintes, ses délais, ses priorités.
Et le vrai souci :
- Pas de chef de projet dédié. Le DSI adjoint cumule ce rôle avec tout le reste. Il fait ce qu’il peut mais il n’a pas le temps.
- Chaque équipe a son propre planning. Le planning de l’infra ne colle pas avec celui de l’équipe applicative. Celui de la sécurité est indépendant des deux. Personne n’a la vue d’ensemble.
- Les risques ne sont pas formalisés. Tout le monde sent qu’il y a des risques, personne ne les a listés. Genre « et si l’hébergeur est en retard sur la mise à dispo de l’environnement de recette ? ». Personne n’y a pensé.
- La direction navigue à vue. Elle demande « où on en est ? », elle reçoit « ça avance ».
Ce qu’on a posé
Jour 1 : le planning qui dit la vérité
On a construit un macro-planning unifié. Toutes les équipes, toutes les dépendances, sur un seul doc. On a identifié 8 jalons critiques et 23 dépendances inter-équipes.
Et là, tout le monde a vu ce que personne ne voulait dire tout haut : 3 jalons étaient incompatibles. L’infra prévoyait de livrer l’environnement de recette le 15 mars. L’équipe de tests devait commencer le 10 mars. Personne n’avait noté le problème parce que personne n’avait mis les deux plannings côte à côte.
| ID | Risque | Impact | Proba | Mitigation | Resp. | Statut |
|---|---|---|---|---|---|---|
| R-01 | Retard livraison env. recette par hébergeur | Critique | Moyen | Négocier livraison anticipée, prévoir env. temporaire | DSI adj. | Mitigé |
| R-02 | Données de migration incomplètes | Critique | Élevé | Dry run migration 3 sem. avant Go-Live | Éq. data | Mitigé |
| R-03 | Résistance utilisateurs en agence | Majeur | Moyen | Communication anticipée + formation pilote | MOA | En cours |
| R-04 | Certificats SSL non renouvelés sur nouveau serveur | Critique | Faible | Check-list sécu intégrée au dry run | Sécu SI | Mitigé |
| R-05 | Conflit de planning recette / migration infra | Critique | Élevé | Décalage 10j négocié avec hébergeur | Chef projet | Mitigé |
Le pilotage au quotidien : simple mais régulier
On a mis en place un rythme simple :
- Comité de pilotage bi-mensuel avec la direction. 15 min, pas plus. Un tableau de bord d’une page.
- Comité projet hebdomadaire. 45 min avec toutes les équipes.
- Point quotidien de 10 min avec les 3 équipes les plus critiques pendant les phases clés.
Le point clé : chaque semaine, la direction avait un tableau de bord d’une page. Avancement par jalon, risques actifs, décisions à prendre. Pas un deck de 30 slides — une page. Si tu peux pas résumer l’état du projet en une page, c’est que tu ne comprends pas ton projet.
| Jalon | Échéance | Resp. | Statut |
|---|---|---|---|
| Livraison env. recette | 25 février | Hébergeur | Fait |
| Migration données - dry run | 10 mars | Éq. data | Fait |
| Campagne de recette | 15 mars - 5 avril | MOA + QA | Fait |
| Homologation sécurité | 8 avril | Sécu SI | Fait |
| Formation conseillers (pilote) | 10-14 avril | MOA | Fait |
| Dry run bascule | 18-19 avril | Chef projet | Fait |
| Go-Live | 26-27 avril | Tous | Planifié |
| Hypercare (support renforcé) | 28 avril - 9 mai | Support + MOA | A venir |
Le truc qui a tout changé : anticiper le conflit de planning
En construisant le planning unifié, on a repéré que la migration infrastructure et la campagne de recette se chevauchaient. Concrètement : l’équipe de tests devait tester sur un environnement que l’infra était encore en train de monter. Recette sur du sable mouvant.
On a négocié un décalage de 10 jours avec l’hébergeur. Ça a coûté 2 réunions et quelques mails. Si on avait découvert le problème le jour J, ça aurait coûté le projet.
Le Go-Live : pas de surprise parce qu’on a répété
Dry run complet 3 semaines avant. Checklist de 120 points — chacun assigné à quelqu’un avec un créneau horaire. Plan de rollback documenté et testé (parce que oui, on a aussi testé le plan B).
La bascule a eu lieu un week-end. 48h de surveillance. Lundi matin, 400 conseillers ouvrent le nouvel outil. Zéro incident bloquant.
Le résultat
Ce qu’on en retient
Une migration, c’est pas un projet technique. C’est un projet de coordination. La techno, les équipes savent faire. Ce qui manque presque toujours, c’est quelqu’un qui met les plannings bout à bout, qui repère les trous, et qui dit « attention, ça va pas coller » avant que ça pète.
Le registre de risques, c’est bête comme outil. Mais quand un risque est écrit noir sur blanc avec le nom de quelqu’un en face, il est traité. Quand il est dans la tête de quelqu’un, il est oublié.
Et le dry run : c’est pas optionnel. C’est comme une répétition générale avant un concert. Le week-end de la migration s’est bien passé parce qu’on l’avait déjà joué une fois.