Caroline B.
Cheffe de marques
Refonte d’application ou de plateforme
Votre application a été spécifiée pour l'entreprise que vous étiez alors. Une refonte d'application web commence donc par relever ce que vos équipes en font aujourd'hui, avant de décider ce que la nouvelle version gardera.
15 ans
d'expérience
250+
missions réalisées
+30
projets en activité
100%
sur-mesure
Ils nous font confiance
LE CONSTAT
L'écart s'est creusé entre votre activité et l'outil qui la porte
Un cahier des charges a fixé, au démarrage, ce que votre application devait faire. Depuis, votre offre s’est élargie et vos façons de facturer ont changé. Le logiciel, lui, applique toujours les règles écrites au départ.
La première dérive porte sur la saisie, et vos équipes l’absorbent à votre place. Une prestation nouvelle se saisit sous une ancienne référence pour que le document sorte juste, et ce que l’écran ne prévoit pas finit dans un champ de commentaire. Ces gestes ne remontent jamais jusqu’à vous, et ils portent une partie de votre activité que rien ne décrit.
La deuxième dérive porte sur vos projets. Chaque fois que vous voulez avancer, la réponse revient au même endroit : cela suppose de toucher au cœur de l’application, et personne ne veut y aller. Vous renoncez, ou vous montez une solution à côté. Ce sont vos priorités qui s’ajustent à l’application, et non l’inverse.
La troisième tient aux personnes. Ceux qui ont défini les règles de départ ont changé de poste ou quitté l’entreprise. Un calcul continue de s’appliquer, sans que quiconque sache le justifier. Vos équipes le contournent, parce que le corriger supposerait de comprendre pourquoi il existe.
Chacune de ces dérives se corrige séparément, et c’est le piège. Vous réparez la saisie, vos projets restent bloqués. Vous débloquez un projet, la règle que personne ne sait justifier continue de s’appliquer. La bonne question porte sur le périmètre de l’outil, non sur ses défauts pris un par un. C’est celle qu’instruisent les travaux réunis sous la refonte et la reprise de projet.
Vous vous reconnaissez ?
Les situations qui font passer une évolution en refonte d'application web
Ces six situations se décrivent depuis votre bureau, à partir de ce que vos équipes vous remontent.
Votre reporting mélange une offre neuve avec l'ancienne
Impossible de savoir ce qu'elle pèse réellement : son chiffre s'ajoute à celui d'une prestation qu'elle a pourtant remplacée.
Une réponse revient à chaque demande d'évolution
Le nombre de demandes simplement abandonnées grossit d'année en année, sans que personne ne le compte ni ne le signale.
Une règle s'applique et personne ne sait plus pourquoi
Impossible de dire si le résultat qu'elle produit est encore juste. Vos équipes le retouchent au jugé avant de le transmettre.
Votre activité s'est déplacée hors du bureau
Vos intervenants saisissent le soir ce qu'ils ont fait dans la journée. Les écrans ont été dessinés pour un grand écran et un clavier.
Deux façons de travailler cohabitent dans le même outil
Un rachat ou l'ouverture d'un site ont laissé deux modes de saisie. Vos récapitulatifs mélangent les deux.
Votre prochain chantier suppose d'ouvrir l'application
Un espace pour vos clients, un raccordement à votre comptabilité : tout part de l'outil actuel.
Dans ces six cas, le besoin a bougé plus vite que l’application. Un outil qui applique fidèlement les règles écrites à sa commande se comporte exactement ainsi. Reste à décider combien de renoncements vous acceptez encore. C’est la question que se posent ceux dont l’application est devenue difficile à faire évoluer.
NOS SERVICES
Ce qu'une refonte d'application web reprend, et ce qu'elle redécide
Un outil déjà en production, ses utilisateurs et son historique : voilà ce que nous reprenons pour cette modernisation. Les trois premières capacités ci-dessous mesurent ce que vaut l'outil actuel ; les quatre suivantes relèvent de la reconstruction. Les trois premières composent l'audit technique qui ouvre le projet, chiffré et sans engagement de suite.
Inventaire de l'application en service
Nous établissons ce que votre outil sait faire, en croisant ce que décrivent vos équipes et ce que contient l'application. Cette liste devient le document de travail du projet.
Usage mesuré dans vos données
Vos équipes disent ce dont elles se servent, vos données disent ce qui a été ouvert et rempli. L'écart entre les deux est instructif.
Décision fonction par fonction
Vous statuez en séance sur le sort de chaque fonction, entre la conserver telle quelle, la refaire autrement et y renoncer, coût affiché en face.
Diagnostic de vos données
Nous les ouvrons avant de vous engager sur un montant. Une part du travail à prévoir dépend de ce qu'elles contiennent.
Contrôle sur vos propres dossiers
Un même dossier réel, traité des deux côtés, et les deux résultats mis face à face.
Reconstruction de l'application
Écrans, règles de calcul, documents produits, rôles : la nouvelle version reprend ce que vous gardez et intègre ce que vous ajoutez.
Dossier des décisions prises
Ce que vous avez abandonné et pourquoi, les règles remises au propre, les écarts jugés acceptables.
Nos dernières réalisations
Toutes nos réalisations 4,8
CE QU'ILS EN DISENT
Nous avons aidé des dizaines de clients dans leur transformation digitale
-
Equipe très à l'écoute, dynamique, réactive, de très bons conseils, très pro, à la fois très techniques mais qui sait aussi se mettre à la place de personnes non averties.
-
Laurence V.
Directrice Marketing
Nous ne pouvons que nous féliciter de notre choix d'agence web : une équipe sympathique, à l'écoute, professionnelle, rigoureuse, technique... présente tout en respectant nos contraintes.
-
Mirela O.
Reponsable Marketing
À l'écoute, disponibles et très créatifs, ils comprennent rapidement les besoins de leurs clients et leurs conseils sont opportuns.
-
Tiffany V.
Responsable Communication
Bonne compréhension des enjeux et attentes, couplée à de la créativité : tout est fluide. J'apprécie leur accompagnement, leur prise en charge et la disponibilité des équipes.
Commencez par l'évolution que vous avez abandonnée
Décrivez-nous une évolution à laquelle vous avez renoncé, et comment vos équipes s’en sortent depuis.
Les décisions que vous prenez à chaque étape de la refonte
-
L'audit technique ouvre le projet : liste des fonctions, usage de chacune mesuré dans vos données, état de la base. Vient ensuite la séance d'arbitrage, où vous statuez fonction par fonction, coût affiché. Le périmètre qui en sort remplace le cahier des charges d'origine. Une refonte se compte ensuite en semaines à quelques mois selon ce périmètre, chiffré précisément à l'issue de cette séance.
-
La maquette sert d'abord à séparer deux choses : ce qui doit rester identique pour vos utilisateurs, et ce que la refonte change volontairement. Vos équipes la manipulent avant le premier développement, au moment où un désaccord se règle en redessinant un écran plutôt qu'en le reconstruisant.
-
Un outil repris se juge sur la vitesse à laquelle vos équipes y retrouvent leurs gestes. Nous conservons donc ce qui les guide déjà, et nous corrigeons ce qu'elles subissent en silence, à commencer par des écrans devenus trop étroits pour ce que vos équipes y saisissent.
-
Le développement porte sur le périmètre retenu, puis vos propres dossiers passent dans les deux outils. Nous vous présentons chaque écart de résultat et vous le classez : changement voulu par la refonte, ou régression que personne n'a demandée.
-
Vos équipes recommencent à formuler des demandes qu'elles avaient cessé de vous adresser. Nous les instruisons avec vous et nous les classons, puis vous décidez lesquelles entrent dans la version suivante et lesquelles attendent. Ce pilotage prend le relais après la livraison dans le cadre d'un contrat de maintenance et d'évolution distinct du forfait de refonte.
Ce que vous nous demandez avant d'engager une refonte d'application
Cela se décide au cas par cas. Si vos écrans conviennent à vos équipes et que la gêne porte sur la lenteur ou sur le coût de chaque intervention, le chantier relève d’une migration technique : la base change, les fonctions restent en place. Si vos équipes contournent les écrans et si votre offre ne rentre plus dans les cases prévues, ce sont les fonctions qui sont en cause, et les refaire à l’identique reproduirait le problème. Les deux se mélangent dans une même application, et c’est l’état des lieux qui donne la proportion.
.Nous vous le demandons, nous le lisons, et nous ne cadrons pas le projet dessus. Ce document décrit ce que vous vouliez au moment de le signer. Depuis, des demandes urgentes ont été traitées en marge, des fonctions ajoutées pour un client parti depuis, d’autres spécifiées puis jamais ouvertes. L’application en service est le seul document à jour sur votre fonctionnement, et vos utilisateurs en sont les seuls lecteurs compétents. Le cahier d’origine garde une utilité : il explique l’intention derrière les règles dont plus personne ne se souvient.
.À la fin de l’audit technique, jamais avant. Un chiffrage donné sur une description en réunion porte sur l’application que vous croyez avoir, et l’écart avec l’application réelle se paie ensuite en avenants. Nous découpons donc la relation en deux. L’audit produit la liste des fonctions, leur usage mesuré, l’état de vos données et le coût de reprise de chaque bloc. Ce document vous appartient : vous engagez la reconstruction avec nous, vous consultez ailleurs, ou vous ne faites rien cette année.
.Cela ne l’empêche pas, et nous traitons cette partie en premier. L’état réel d’une base se découvre en l’ouvrant. Nous y trouvons la même société sous deux fiches créées par deux services, des champs qui ont servi à autre chose que ce que leur nom indique, des rattachements perdus entre un dossier et son client. Chaque cas se traite, à condition d’être vu avant que la reconstruction démarre. L’audit les recense donc un par un, avec le travail de remise en ordre que chacun représente. C’est ce qui se corrige le plus mal en cours de route. Cette phase pose aussi la question des accès : qui peut consulter ces données pendant qu’elles transitent d’un outil à l’autre, et sous quelle sauvegarde on revient en arrière si un contrôle révèle un écart après la bascule.
.Par comparaison sur des cas venus de votre activité. Nous constituons avec vos équipes un jeu de dossiers où figurent surtout les cas difficiles : celui qui a changé de main deux fois, celui qui porte une remise accordée hors barème, celui qu’un client a fait annuler après facturation. Nous les traitons dans l’ancien outil puis dans le nouveau, et nous confrontons les résultats montant par montant. Une refonte produit des écarts voulus : le nouveau calcul ne rend pas la même somme que l’ancien, parce que vous avez décidé de le changer. Chaque écart passe devant vous, en changement décidé ou en régression à corriger.
.Le service est le même, le chantier change de nature. Sur un outil porté par un seul service, vous arbitrez avec un interlocuteur et la reconstruction suit le rythme des livraisons. Dès que plusieurs services y travaillent, chacun défend son écran, et ce qui arrange l’un gêne l’autre. Il faut alors une instance qui tranche, et un découpage de l’outil posé avant tout développement. Le calendrier s’allonge d’autant.
.Ce qui compte, ce sont les accès. Il nous faut le code, l’hébergement et les données pour établir l’état des lieux. Quand vous disposez des trois, l’absence du prestataire d’origine ne nous gêne pas. Sinon, la réclamation part de vous, puisque le contrat vous lie à lui et pas à nous. Notre part est de vous dire quoi demander, à qui, et sous quelle forme le recevoir pour que ce soit exploitable. Rien ne se chiffre tant que ce point n’est pas réglé. Quand il devient le sujet principal, vous n’êtes plus sur une refonte mais sur une reprise de projet existant.
. POUR ALLER PLUS LOIN
Décider une refonte d'application web, et la tenir jusqu'au bout
Ce qu’un outil déjà en service impose au projet
Construire un outil qui n’existe pas encore laisse toute latitude. Reconstruire un outil en service pose trois contraintes que la création ignore. Des gens travaillent dedans aujourd’hui et y travailleront demain. Des années d’activité y sont enregistrées et doivent rester consultables. Des règles s’y appliquent, certaines longuement discutées chez vous, d’autres arrivées par accident.
Le cadrage change donc de nature. Sur une création, la question est de savoir ce que vous voulez. Sur une refonte, elle devient de savoir ce que vous avez et ce qui en sert encore. C’est plus long à mener, et c’est ce qui évite de reconstruire des défauts que personne n’avait vus.
Le moment où réparer cesse de rapporter
Le moment où une application cesse d’être réparable ne s’annonce pas. Elle traverse une période où chaque correction reste possible, mais où son coût dépasse peu à peu ce qu’elle rapporte. Repérer cette période vous évite deux erreurs opposées : refondre un outil qui tenait encore, ou payer des correctifs sur un outil qui ne vous rendra plus rien.
Trois indices se lisent dans vos propres documents, sans nous. Le nombre de demandes que vous avez rayées de vos priorités parce que leur chiffrage dépassait leur intérêt. La part de vos interventions qui répare une conséquence au lieu d’ajouter quelque chose. Et le décalage entre le moment où votre métier change et celui où l’outil suit. Aucun des trois ne décide à votre place. Ensemble, ils justifient d’instruire la question, point de départ d’une refonte d’une application web existante.
Refonte d’application ou refonte de plateforme, ce qui change
Deux chantiers de nature différente portent le même nom, et les confondre fausse à la fois le budget et le calendrier. Ce qui les sépare ici n’est pas la nature du problème, traitée plus haut, mais le nombre de services qui travaillent dans l’outil. Les deux questions sont indépendantes : votre application peut avoir un socle à changer et un seul utilisateur, ou des fonctions à revoir et cinq services autour.
Quand l’outil sert un seul service, la refonte reste un chantier de reconstruction. Vous arbitrez avec un interlocuteur, le travail avance un module après l’autre, et l’ancienne version reste disponible tant que la nouvelle n’a pas fait ses preuves. Nous le détaillons sur migrer une application vers une techno moderne.
Quand plusieurs services y travaillent, la refonte devient d’abord un chantier d’organisation. Chaque module fonctionne, et c’est l’ensemble qui coûte : le même dossier saisi deux fois par deux personnes, deux rapports qui donnent deux totaux. Le premier travail consiste à redécouper l’outil en ensembles cohérents et à savoir qui tranche pour chacun. C’est le sujet de la page refondre une plateforme métier.
Des situations commencent comme la première et se révèlent être la seconde. Une application isolée finit par recevoir un accès pour la comptabilité, puis un écran pour l’après-vente. C’est l’état des lieux qui range votre cas dans l’une ou l’autre catégorie, et il vaut mieux le savoir avant de fixer le budget.
Une refonte se juge sur les demandes qu’elle rend possibles
Après la mise en service, la tentation est de mesurer le résultat sur ce qui se voit : des écrans plus clairs, des utilisateurs qui se plaignent moins. Ces effets sont réels, et ils cessent de se voir une fois l’habitude prise.
Le résultat durable tient dans les demandes que votre métier formule à nouveau, après avoir cessé de les adresser à un outil qui ne pouvait pas les prendre. Un tarif à modifier pour un client, un document à produire dans le format qu’un partenaire exige. Leur retour vous oblige à les classer, et vous gardez pour cela l’inventaire des fonctions et les décisions du projet.
Vous décidez seul de la suite
La propriété se vérifie à un moment précis, la première évolution après la livraison. Votre métier réclame une règle nouvelle. Soit vous l’ajoutez quand vous le décidez et avec l’équipe que vous voulez, soit vous attendez qu’un éditeur veuille bien l’inscrire à son programme. Le code et les données de votre application vous appartiennent intégralement, ce qui vous place dans le premier cas.
Un troisième élément vous revient, et celui-là ne se lit pas dans le code : le dossier des décisions du projet. Il garde la trace des écarts de résultat que vous avez validés en connaissance de cause, et de l’argument qui a fait écarter telle fonction. Sans lui, la discussion se rouvre entière dans quelques années, devant des gens qui n’étaient pas dans la salle.
