Refondre une application métier, ce n'est pas refaire un site : c'est remplacer un outil dont plus personne ne connaît toutes les règles, pendant qu'il continue de tourner et que les utilisateurs continuent de s'en servir. Le déroulement est bien balisé, mais il tient peu de place dans les propositions commerciales — on y parle surtout de technologies. Voici les étapes réelles, dans l'ordre où elles arrivent, et ce qui se décide à chacune.
Ce qui fait l'ampleur : la surface, pas le volume
Première surprise pour beaucoup de maîtres d'ouvrage : le nombre d'enregistrements ne pèse presque rien. Quelques milliers de fiches, quelques centaines d'utilisateurs simultanés au grand maximum — aucun serveur moderne ne bronche. La seule vraie question de charge, à cette échelle, c'est l'envoi d'e-mails en masse, et elle se règle en s'appuyant sur un routeur spécialisé.
Ce qui fait l'ampleur, c'est la surface fonctionnelle : plusieurs espaces (site public, espace membre, espace de gestion, administration), une trentaine de fonctions métier, et surtout des rôles qui se croisent avec des périmètres. Deux personnes portant le même rôle ne voient pas les mêmes lignes selon la région, le service ou la délégation dont elles ont la charge. Ce n'est pas une liste de rôles, c'est une matrice de rôles par périmètre — et chaque écran, sans exception, doit filtrer ses données en conséquence.
C'est ce décalage — petit par le volume, vaste par la surface — qui doit gouverner l'architecture et le budget. Un projet chiffré sur le volume est un projet sous-chiffré.
Étape 1 — Le cadrage, avant toute ligne de code
Le cadrage représente couramment un dixième de la charge totale. C'est ce qui évite d'avoir à refaire la refonte.
Concrètement : une série d'ateliers métier, un par grand domaine, où l'on fait dire aux utilisateurs ce que l'outil actuel fait vraiment — y compris les contournements, les tableurs parallèles et les règles que personne n'a écrites. En sortie : des spécifications détaillées, le modèle de données cible, l'arborescence et les maquettes de chaque espace, un dossier d'architecture et l'analyse d'impact sur les données personnelles.
Un atelier de validation avec un panel d'utilisateurs réels — pas seulement le comité de pilotage — clôt la phase. Il coûte une journée et corrige des malentendus qui, découverts six mois plus tard, coûtent des semaines.
Étape 2 — Le socle, et les droits en premier
Vient l'infrastructure invisible : environnements de préproduction et de production, chaîne de livraison automatisée, authentification (politique de mot de passe, double authentification), journal d'audit, système de composants accessible et responsive.
Et, au même moment, le modèle de droits. C'est délibéré : tout écran construit avant que les droits soient posés devra être repris. Le bon réflexe est de les exprimer en règles paramétrées plutôt qu'en code — un croisement rôles × périmètres qui se configure se relit, s'audite et évolue sans nouvelle prestation ; le même croisement dispersé dans le code devient une dette immédiate.
Étape 3 — Les lots métier, livrés par incréments
Le reste se découpe en lots, chacun produisant un incrément recettable en préproduction, documentation comprise. Le commanditaire voit fonctionner quelque chose toutes les quelques semaines, et non une démonstration finale au bout d'un an. C'est la meilleure protection contre l'effet tunnel, et le meilleur outil de renégociation en cours de route : on peut décaler un lot, on ne peut pas décaler un tunnel.
L'ordre habituel suit les dépendances : le référentiel des personnes d'abord, puis le cycle de gestion (adhésion ou dossier, facturation, paiement en ligne, régularisations), puis la communication et les sondages, puis l'exploitation des données, enfin le site éditorial.
Une distinction utile pour le budget : ce qui est standard et ce qui ne l'est pas. Un site de contenu, un annuaire, une recherche, un module d'offres d'emploi sont des besoins classiques ; en s'appuyant sur des briques existantes plutôt qu'en les réécrivant, ils pèsent moins d'un quart de la charge. Tout le reste — les règles propres à votre organisation — ne s'allège pas. C'est là qu'il faut mettre l'argent, et c'est là que le sur-mesure se justifie.
Étape 4 — La reprise de données, le poste que tout le monde sous-estime
Aucune phase ne réserve autant de mauvaises surprises. Une base en service depuis quinze ans contient des champs libres où se sont logées des informations que personne n'a documentées, des doublons, des codes obsolètes et des conventions qui ont changé trois fois.
Le déroulement qui tient : audit de la base existante avant le chiffrage définitif ; cartographie champ à champ et règles de transformation écrites ; scripts de migration rejouables — on ne migre jamais une seule fois ; rapports d'anomalies remis au commanditaire, à qui revient l'arbitrage sur les cas douteux ; au moins trois répétitions à blanc ; enfin une recette portant sur les données elles-mêmes, pas seulement sur les écrans.
C'est le seul poste qu'il est raisonnable d'annoncer comme révisable après l'audit. Un prestataire qui le chiffre au forfait sans avoir ouvert la base ancienne prend un risque — ou l'a déjà provisionné dans son prix.
Étape 5 — Recette, bascule, garantie
La recette fonctionnelle appartient au commanditaire : ses équipes déroulent leurs cas réels en préproduction, les anomalies sont corrigées, on recommence. Puis la bascule, sur un créneau choisi, suivie d'une vérification d'aptitude — l'outil fait ce qu'il doit — puis d'une période de service régulier, où l'on observe le comportement en conditions réelles.
L'ancien système reste accessible en lecture seule quelques semaines. Ce filet ne sert presque jamais ; il coûte peu et change complètement la sérénité du jour J.
La documentation est remise à chaque étape.
Une règle simple, et qui change le rapport au projet : chaque étape donne lieu à une remise de la documentation correspondante — la documentation technique et la documentation utilisateur, mises à jour et livrées avec l'incrément qu'elles décrivent.
Le cadrage remet ses spécifications et son dossier d'architecture. Le socle remet le schéma de la base, la matrice des droits et les procédures d'exploitation. Chaque lot métier remet le mode d'emploi des écrans qu'il ouvre, par profil d'utilisateur — ce que voit un gestionnaire n'est pas ce que voit un membre. La reprise de données remet ses règles de transformation et ses rapports d'anomalies. La mise en production remet le manuel d'exploitation et les supports de formation.
Écrite à chaud, elle sert immédiatement : c'est elle qui rend possibles la recette, la formation, puis la reprise par une autre équipe. C'est aussi ce qui fait la différence entre une réversibilité réelle et une réversibilité contractuelle.
Deux régimes de données, deux outils
Une remarque d'architecture qui revient sur tous ces projets. Le contenu éditorial et les données de gestion n'obéissent pas aux mêmes lois : le premier change souvent, s'écrit à plusieurs mains et doit être indexé par les moteurs de recherche ; les secondes changent peu, sont soumises à des droits fins et ne doivent jamais fuir.
Vouloir les traiter avec un outil unique oblige à céder sur l'un des deux — soit un back-office éditorial pénible, soit des données personnelles gérées avec la légèreté d'un site vitrine. Les séparer, avec une session partagée entre les deux, est presque toujours le bon choix. C'est aussi, en pratique, le point d'architecture le plus délicat du projet : à traiter tôt, jamais à la fin.
La réversibilité se prépare le premier jour
Dernier point, souvent relégué en annexe des contrats alors qu'il conditionne tout le reste : que se passe-t-il si le prestataire disparaît ?
La réponse tient à trois choix pris au démarrage. Les données vivent dans une base standard dont le schéma est le vôtre, et non le schéma interne d'un produit : elles restent exploitables même si la couche applicative s'arrête. Le code, l'infrastructure décrite en fichiers et la documentation d'exploitation vous sont remis au fil de l'eau, pas à la livraison finale. Et les dépendances tierces sont distinguées explicitement du code écrit pour vous, licences comprises.
Un test simple, à poser en réunion de lancement : « si vous vous arrêtez demain, qu'est-ce qui reste exploitable, et par qui ? » La qualité de la réponse en dit plus long que n'importe quelle plaquette.
Combien de temps ?
Le calendrier d'une refonte de cette surface — plusieurs espaces, une matrice de droits, un cycle de gestion complet et une reprise de données — se fixe au terme du cadrage, quand le périmètre et les lots sont écrits.
Un point mérite d'être dit sans détour : le développement assisté par IA a déplacé cette ligne. À périmètre égal, il divise par au moins deux le temps de fabrication d'un développement classique — écriture du code, tests, scripts de reprise, documentation d'exploitation. C'est la part du projet qui s'automatise le mieux, et elle se mesure lot après lot, sur des incréments recettables.
Ce que l'IA ne comprime pas, en revanche, ce sont les décisions : les ateliers de cadrage, les arbitrages sur vos règles de gestion, la recette par vos utilisateurs, la préparation de la bascule. Ce temps-là reste celui de votre organisation, et c'est très bien ainsi : c'est lui qui fait la qualité du résultat. Les calendriers spectaculairement courts, eux, ne suppriment pas le travail : ils le déplacent après la mise en production, quand il coûte le plus cher.
Vous envisagez de remplacer une application vieillissante ? Nous réalisons des audits de l'existant avec chiffrage et plan de lotissement écrits, indépendamment de toute réalisation ultérieure — parlons-en.