Refonte d’une application web existante
Vos équipes ont appris à travailler avec les limites de l'outil actuel. Une refonte d'une application web existante commence donc par séparer ce qui relève de votre métier de ce qui compense une limite de l'écran.
d'expérience
missions réalisées
projets en activité
sur-mesure
Vos habitudes de travail se sont formées autour d'un outil qui a vieilli
Votre application tourne, elle porte votre activité, et l’idée de la refaire revient à chaque réunion. La question qui compte arrive juste après celle du budget : que reste-t-il de la version en service ?
La réponse spontanée consiste à reprendre ce que vos utilisateurs font aujourd’hui. Elle a un défaut : une part de ce qu’ils font tient à ce que l’écran leur impose, et rien ne distingue cette part du reste tant que personne n’a posé la question.
Ces gestes se sont installés sans décision. Un champ sert à noter une information que l’outil ne prévoit pas. Une saisie se fait en deux fois parce que le premier écran refuse un cas courant. Un dossier se rouvre pour corriger ce qu’un contrôle a bloqué à tort. Vos nouveaux arrivants les apprennent au même titre que vos procédures, et plus personne ne sait lesquels viennent de votre métier.
Le tri des gestes et le dessin des écrans vont ensemble. Redessiner sans trier reconduit les détours dans une version neuve. Trier sans redessiner laisse vos utilisateurs devant les mêmes obstacles. Le chantier porte donc sur les deux à la fois, et c’est ce travail que rassemble une refonte d’application ou de plateforme.
Les situations qui vous décident à refaire une application encore utilisée
Elles se repèrent dans vos réunions et dans les demandes que vos équipes vous adressent.
La commande paraît simple, et elle fige au passage tout ce qu'elles ont appris à contourner.
Les deux devis sont sur votre bureau, et vous cherchez dans chacun ce qu'il conserve de l'outil actuel.
Elles remplissent d'abord ce que l'application réclame, puis ce dont le dossier a besoin.
Un client demande une démonstration, un candidat vous interroge sur vos outils. Vous préférez décrire plutôt qu'ouvrir l'écran.
Chaque passage impose une recherche, et la journée se remplit de ces allers-retours.
Vos équipes remplissent des champs devenus inutiles, et le doute sur ce qui sert encore les fait tous remplir.
Ces six situations portent toutes sur ce que vos équipes vivent devant l’outil, jamais sur ce qui tourne derrière. Une application peut au contraire satisfaire ses utilisateurs et devenir coûteuse à faire évoluer, parce que sa base technique a vieilli. Ce cas relève d’un autre chantier, décrit sur la page migrer une application vers une techno moderne.
Observer, trier, redessiner une application en service
Nous intervenons sur des applications qui portent une activité en cours, avec leurs utilisateurs et leurs habitudes. Ces capacités valent pour un outil dont un seul métier se sert. Dès que plusieurs services y travaillent et se renvoient des dossiers, le travail commence par un découpage, traité sur refondre une plateforme métier.
Observation de vos utilisateurs au travail
Nous les regardons se servir de l'application actuelle, sur leurs vrais dossiers et à leur rythme.
Tri entre règle métier et contournement
Chaque façon de faire actuelle reçoit une étiquette avant que son sort soit décidé.
Parcours quotidiens raccourcis
Nous comptons les gestes d'un dossier courant, puis nous les réduisons dans la nouvelle version.
Recherche et filtres refaits
Vos équipes retrouvent un dossier ancien sur leurs propres critères, sans parcourir la liste entière.
Écrans utilisables hors du bureau
Saisie sur téléphone et sur tablette pour les tâches qui se font debout ou en déplacement.
Explications intégrées à la saisie
La règle s'affiche à l'endroit où elle s'applique, plutôt que dans un document tenu à part.
Repères d'usage avant et après
Nous relevons quelques mesures simples sur l'outil actuel, puis les mêmes sur la nouvelle version.
Journal des changements annoncés
Chaque écart voulu avec l'ancienne version est écrit et daté, pour que vos équipes le découvrent avant la mise en service.
Nos dernières réalisations
Toutes nos réalisationsNous avons aidé des dizaines de clients dans leur transformation digitale
Quelle manipulation vos équipes ne savent plus expliquer ?
Un seul geste que vos équipes répètent chaque jour sans en connaître l’origine suffit à lancer l’audit. Décrivez-le-nous.
Nos étapes quand l'application ne peut pas s'arrêter
-
Le projet s'ouvre par l'audit technique, auquel nous ajoutons quelques journées passées avec vos utilisateurs sur leurs dossiers en cours. Chaque façon de faire relevée est classée devant vous, puis entre au périmètre ou en sort. Le prix de la refonte se connaît à la fin de cet audit, jamais avant.
-
Nous reprenons le dessin des parcours les plus fréquents, en commençant par celui qui occupe le plus de temps dans la journée. Vos utilisateurs les essaient sur maquette, un dossier réel en main. Une habitude défendue en réunion se révèle parfois abandonnée dès qu'un autre chemin existe.
-
Vos collaborateurs passent des heures par jour devant ces écrans, et vous les montrez parfois à l'extérieur. Nous reprenons ce qui fatigue à la longue : la densité d'informations affichées d'un coup, la place des actions courantes, le repérage d'un dossier dans une liste. L'outil redevient présentable sans ralentir ceux qui y travaillent.
-
La construction suit l'ordre de fréquence : les écrans les plus ouverts partent en premier, pendant que le reste de l'application continue de tourner sur l'ancienne version. Vos utilisateurs voient donc leur quotidien changer écran par écran plutôt que d'un coup, et nous corrigeons la suite avec ce qu'ils en disent.
-
La nouvelle version arrive chez des gens qui s'accommodaient de l'ancienne. Nous relevons ce qui les ralentit, ce qu'ils cherchent sans le trouver, le geste refait par réflexe : cette observation ferme le forfait de refonte, elle y est comprise. Les ajustements qu'elle fait ressortir, eux, ne le sont plus : ils relèvent du contrat de maintenance et d'évolution, qui prend le relais dès que cette observation se conclut, distinct du forfait de refonte qui s'arrête là.
Ce qui change, ce qui reste, et qui le décide
Parfois non, et nous le disons avant le chiffrage. Une partie des gênes vient d’une règle interne qui a changé sans que personne l’écrive, ou d’un partage de tâches devenu flou entre deux postes. Ces cas se repèrent pendant l’observation : deux collaborateurs du même service traitent la même tâche de deux façons, sur le même écran, sans que l’écran y soit pour quelque chose. Une refonte ne corrige pas ces situations, elle les rend visibles, ce qui est déjà utile. Vous décidez alors ce qui relève de l’outil et ce qui relève de votre organisation, avant d’engager la moindre reconstruction.
.Par une question posée à l’utilisateur devant son écran : que se passe-t-il si vous ne le faites pas ? Une règle de votre métier produit une réponse tournée vers l’extérieur, un client mal facturé, une pièce manquante au dossier, un engagement non tenu. Un contournement produit une réponse tournée vers l’application, l’écran refuse, le champ est trop court, le contrôle bloque. La troisième réponse est la plus instructive : personne ne sait, parce que personne n’a essayé autrement depuis des années. Ces cas passent devant vous, et vous décidez de les retirer ou de les garder en connaissance de cause.
.Rarement l’utilisateur le plus expérimenté. Vos utilisateurs décrivent leur travail avec une précision que personne d’autre n’a, et ils défendent en même temps les gestes qui leur ont coûté le plus à apprendre. L’addition de leurs demandes reconstitue l’application actuelle. Le tri revient donc à quelqu’un qui peut dire qu’une pratique s’arrête et l’assumer devant l’équipe : le responsable du métier concerné, parfois le dirigeant sur une application qui porte l’activité principale. Nous lui présentons chaque façon de faire avec ce que sa disparition change pour les personnes qui l’appliquent aujourd’hui.
.Comptez quelques semaines à quelques mois, selon l’étendue de ce que l’audit fait ressortir. Ce délai varie moins avec le nombre d’écrans qu’avec le nombre de façons de faire à trancher. Une application utilisée par une équipe qui travaille de la même manière se refait vite. La même application, utilisée par trois équipes qui ont chacune adapté les écrans à leur façon, demande un temps de décision avant le premier dessin. Nous mesurons cet écart pendant l’observation, et c’est lui qui fixe le calendrier plutôt que la taille de l’outil.
.Oui, et c’est souvent le meilleur départ. Le relevé d’usage montre où se concentrent les ouvertures de votre outil, et cette répartition est rarement égale d’un écran à l’autre. Refaire les écrans les plus sollicités change la journée de vos utilisateurs sans engager la reconstruction complète. Deux conditions y sont attachées. Les écrans repris doivent former un parcours complet, sinon un dossier commence dans le neuf et finit dans l’ancien. Et le reste de l’application continue de fonctionner sans être touché, ce que le relevé d’usage vérifie avant tout découpage.
.Ils perdent du temps, et vous le prévoyez. Une personne qui connaît une saisie par cœur va plus vite que sur une version mieux dessinée qu’elle découvre. Cette perte se résorbe à mesure que les gestes se reprennent, à condition que la première semaine soit préparée : un interlocuteur identifié chez vous pour recueillir les blocages, les dossiers urgents repérés à l’avance, et une liste des changements que chacun a lue avant. Le choix de cette semaine vous revient, et il vaut mieux l’écarter de vos périodes les plus chargées.
.L’accès à un dossier reste limité aux personnes qui en ont besoin pour leur poste, et cette liste de droits se construit avec vous pendant l’audit plutôt qu’après la mise en service. Un dossier qui porte une information sensible pour la personne concernée, un salaire, un motif d’absence, un état de santé, reçoit un accès encore plus restreint que le reste de l’application, décidé cas par cas avec vous. La nouvelle version se raccorde aussi à ce que vous utilisez déjà : votre comptabilité, votre messagerie, un outil métier tiers envoient ou reçoivent l’information par une connexion prévue à cet effet, plutôt que par un fichier recopié à la main d’un outil à l’autre. Ces raccordements se listent avec vous pendant l’audit, au même titre que les façons de faire à trier.
.Refaire une application sans refaire ses défauts
Refaire à l’identique revient à racheter vos contournements
Le devis d’une refonte d’une application web existante se calcule sur ce qu’il y a à construire. Or une application en service contient des fonctions demandées par le métier et des fonctions nées d’un manque : un champ détourné de son usage, un écran de rattrapage, une sortie de fichier créée pour compenser un état que l’outil ne produit pas. Les secondes se reconstruisent au même titre que les premières, et elles entrent dans le même devis.
Elles coûtent ensuite une deuxième fois. Chaque fonction reprise se teste, s’explique aux utilisateurs, se corrige quand un défaut apparaît, et se transporte dans la version d’après. Un écran qui existait pour compenser le défaut d’un autre se paie donc pendant toute la vie de la nouvelle version, alors que le défaut d’origine vient d’être corrigé.
La commande « la même chose en mieux » a donc un prix, et il se voit rarement sur le devis. Il apparaît le jour où vous demandez une évolution simple sur la nouvelle version et où la réponse mentionne trois écrans à modifier ensemble.
Trois sorts possibles pour chaque façon de faire actuelle
Chaque façon de faire relevée finit dans l’une de trois catégories, et chacune appelle une décision différente de votre part.
Cette distinction, posée plus haut à partir de la question devant l’écran, tranche ensuite le sort de chaque façon de faire : une règle de votre métier se reprend telle quelle, même quand elle paraît étrange vue de l’extérieur — un délai de validation particulier, une remise accordée à une catégorie de clients, un document produit dans un ordre imposé par un partenaire — et un contournement disparaît, à condition que la nouvelle version traite le cas qui l’avait fait naître.
Une habitude sans cause identifiée forme la catégorie la plus intéressante. Elle vient souvent d’une règle abandonnée depuis longtemps, ou d’une consigne donnée par quelqu’un qui a quitté l’entreprise. Ces cas se traitent un par un, avec la personne qui décide. La même discipline vaut quand la question porte sur des fonctions entières plutôt que sur des gestes, ce que traite l’arbitrage fonction par fonction d’une refonte d’application.
Vos gains se jouent sur l’écran ouvert cent fois par jour
Les écrans de votre outil ne sont pas ouverts au même rythme, et l’écart entre le plus sollicité et le plus rare se mesure avant d’engager le travail. Cette répartition se lit dans l’application elle-même, sans avoir à interroger qui que ce soit.
Elle change l’ordre du projet. Un écran ouvert cent fois par jour mérite une discussion sur sa disposition, sur le nombre de ses champs et sur ce qu’il affiche par défaut. Un écran ouvert deux fois par mois mérite d’exister et de fonctionner, sans plus. Le temps de conception se place là où il rend quelque chose à vos équipes.
Elle change aussi la façon dont la refonte se juge. Un geste retiré d’une opération répétée toute la journée pèse davantage qu’une page rare rendue élégante, et vos utilisateurs le ressentent avant de savoir l’expliquer.
Les trois relevés du premier mois
Une refonte se juge sur des repères choisis avant sa mise en service, sinon la discussion se fait sur des impressions. Trois relevés suffisent, et ils se prennent aussi bien sur l’application actuelle que sur la nouvelle.
- Le temps qu’un dossier courant demande, de son ouverture à sa clôture.
- Le nombre de dossiers repris après coup pour corriger une saisie.
- Le nombre de champs remplis pour créer un dossier, de bout en bout.
Ces trois relevés se comparent sur deux périodes équivalentes, en écartant la semaine de démarrage, qui mesure surtout la découverte. Ils vous donnent de quoi arbitrer la suite : ce qui a fonctionné s’étend aux écrans encore anciens, ce qui n’a rien changé s’examine avant d’être reproduit ailleurs.
Vos données restent les vôtres, y compris le jour où vous partez
Une application refaite reste l’endroit où votre activité s’enregistre. La question qui compte à long terme porte sur ce que vous pouvez faire de ce qui s’y trouve, sans avoir à nous le demander.
Votre application vous appartient en totalité, son code comme les données qu’elle contient. Vous restez libre de confier la suite à une autre équipe, de raccorder un autre outil à ces données, ou de répondre à un client qui réclame les siennes.
Ce point se pose au cadrage plutôt qu’après coup. Savoir quelles informations devront un jour sortir de l’application, et vers quoi, change la façon dont elle est construite. La même question posée trois ans plus tard se traite en travail supplémentaire.