Caroline B.
Cheffe de marques
Migrer une application vers une techno moderne
Votre outil fonctionne encore, et le devis de la prochaine évolution vous fait hésiter. Migrer une application vers une techno moderne demande un découpage par lots : nous reconstruisons module par module, pendant que vos équipes continuent de travailler dessus.
15 ans
d'expérience
250+
missions réalisées
+30
projets en activité
100%
sur-mesure
Ils nous font confiance
LE CONSTAT
Votre application coûte de plus en plus cher à laisser en l'état
Aucune fonction ne casse, et c’est justement ce qui retarde la décision. Une demande d’évolution que vous jugiez simple revient chiffrée plus cher chaque année, sans qu’aucun incident ne force la conversation.
Elle monte d’abord sur les devis d’évolution. Une demande que vous jugez simple revient chiffrée plus haut que la même demande l’année précédente. Votre prestataire facture le temps de comprendre un code que personne n’a documenté, puis de vérifier qu’une correction à un endroit ne casse rien à trois autres. C’est le coût d’une dette technique jamais remboursée : plus votre application vieillit sans être reprise, plus elle s’alourdit et plus ce temps de précaution s’allonge.
Elle monte ensuite sur le nombre de personnes capables d’intervenir. Vous tenez à un seul interlocuteur pour un outil qui porte votre activité, et le remplacer suppose de payer à son successeur le temps d’apprendre votre socle avant qu’il touche au premier écran.
Le reste vient de l’extérieur, et vous le négociez encore moins. Votre assureur, vos clients grands comptes et les services que votre application appelle posent chacun leurs conditions, à des dates que vous ne choisissez pas. Vous le payez sur votre garantie, sur un contrat en renouvellement, ou sur une fonction qui s’éteint.
Ces pressions arrivent à des moments différents. Vous supportez le prix des évolutions encore un temps, tenir à une seule personne devient un problème le jour d’un départ, l’assurance et l’audit client tombent à date fixe. Une refonte d’application ou de plateforme les traite ensemble ; le cas qui nous occupe ici est précisément celui où le socle a vieilli au point de freiner chaque devis, le sujet des six situations qui suivent.
Vous vous reconnaissez ?
Ce qui vous décide à migrer une application vers une techno moderne
Six situations repérables sans audit, dans vos devis, votre planning et ce qui vous arrive de l’extérieur.
Votre hébergeur vous annonce une migration forcée
Le socle qui fait tourner votre application quitte son catalogue. Vous héritez d'une échéance subie et d'un devis à obtenir vite.
Le devis d'évolution dépasse le bénéfice attendu
Vous renoncez à des demandes métier parce que le chiffrage les rend absurdes. Votre feuille de route suit ce que l'application accepte.
Une seule personne sait encore y toucher
Vous calez vos mises en production sur ses disponibilités. Son départ transformerait chaque correction en enquête.
Un client important vous audite avant de resigner
Son questionnaire fournisseur porte sur vos mises à jour de sécurité et votre hébergement. Vos réponses conditionnent le renouvellement.
Un service extérieur a coupé son ancien raccordement
Paiement, transport, messagerie ou comptabilité : le prestataire ferme son ancienne interface, et une fonction de votre application s'éteint.
Votre assureur cyber vous interroge sur vos logiciels
Sa question porte sur ceux qui ne reçoivent plus de mise à jour. La réponse honnête pèse sur votre garantie et sur votre prime.
Ces six signaux annoncent une échéance, ils ne mesurent pas le travail à prévoir. Deux applications qui les cochent toutes peuvent demander l’une la reprise de quelques modules, l’autre une reconstruction entière. Ce qui tranche tient dans l’application elle-même : les fonctions encore utilisées, l’état des données, les raccordements en place. C’est l’objet d’un audit technique, qui produit un état des lieux chiffré avant que vous engagiez quoi que ce soit.
NOS SERVICES
Notre travail sur une migration d'application encore utilisée tous les jours
Nous reprenons des applications en service, avec leurs données et leurs utilisateurs. Quand le sujet porte sur les évolutions bloquées plutôt que sur le socle technique, il rejoint le cas d'une application devenue difficile à faire évoluer.
Relevé de l'existant
Nous parcourons écran par écran ce que l'application fait, fonctions oubliées comprises.
Périmètre repris et périmètre abandonné
Vos équipes défendent chaque fonction devant vous avant que nous la reconstruisions. Ce qui tombe ici sort du budget.
Reprise de l'historique
Dossiers, pièces jointes, écritures anciennes : nous fixons avec vous ce que nous transportons et ce que nous nettoyons.
Refonte des raccordements
Nous réécrivons les liens vers vos autres outils sur les interfaces actuelles de chaque service.
Reconstruction par lots
Un module livré, puis le suivant, sans jamais couper l'outil que vos équipes utilisent.
Bascule par groupe d'utilisateurs
Un service passe en premier, et ses utilisateurs corrigent la suite avant que les autres suivent.
Reprise des comptes et des droits
Qui voit quoi, qui valide quoi : nous relevons les règles en vigueur et les rétablissons une par une dans la nouvelle version.
Jeu de vérification
Nous rejouons de vrais dossiers dans les deux versions et relevons chaque écart.
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.
Qui sait encore intervenir sur votre application ?
Contactez-nous, nous menons nous-mêmes le relevé de l’existant à partir de votre application telle qu’elle tourne aujourd’hui.
Du relevé de l'existant à la bascule du dernier module
-
Nous relevons ce que l'application fait, qui s'en sert et ce qui la relie à vos autres outils. Nous classons ensuite chaque fonction en reprise, refonte ou abandon, devant vous. Vous fixez le budget avec ce tri, bien avant le choix du socle technique.
-
Nous produisons un état de vos bases existantes : doublons, champs remplis à moitié, pièces jointes rattachées à des enregistrements disparus. Vos équipes métier tranchent ce qui est gardé, corrigé ou archivé à part, avant que la reconstruction des écrans ne commence.
-
Nous réécrivons les liens vers vos autres outils sur leurs interfaces actuelles, plutôt que de les déplacer tels quels. Nous fixons aussi les règles de la cohabitation à venir : quelle version fait autorité sur quelle donnée, et comment comptes et droits restent alignés tant que les deux tournent.
-
Ce même équilibre, reconstruire sans arrêter l'ancienne version, structure le développement : chaque lot passe le jeu de vérification sur de vrais dossiers, puis un groupe d'utilisateurs bascule avant les autres. Le chemin de retour reste ouvert tant que la bascule attend sa validation.
-
Après la bascule, nous suivons encore, dans le cadre du forfait de migration, les écarts remontés par vos équipes et l'état des raccordements extérieurs. Nous vous proposons ensuite un suivi du socle : il relève d'un contrat de maintenance et d'évolution distinct du forfait de migration, pour que la migration suivante porte sur des évolutions choisies plutôt que sur un rattrapage subi.
Bascule, données et périmètre d'une migration d'application
Par lots, sauf sur un périmètre très réduit. La réécriture complète en une fois gèle vos évolutions pendant toute la reconstruction, sans rien vous montrer de votre investissement avant la fin. Elle concentre en plus sur une seule journée toutes les régressions, ces fonctions qui marchaient avant et qui cessent de marcher. La reprise par lots livre un module à la fois, l’ancienne version restant disponible. Elle coûte davantage, parce qu’il faut faire cohabiter les deux versions. En échange, votre activité continue. Nous recommandons la bascule en une fois quand l’application tient en quelques écrans, sans historique lourd à reprendre.
.Nous le transportons, à condition que vous décidiez ce qu’il contient. Nous trouvons dans les bases anciennes des dossiers en double, des champs remplis à moitié, des pièces jointes rattachées à des enregistrements supprimés. Reprendre cela tel quel revient à réinstaller le désordre dans un outil neuf. Nous produisons un état de vos données, vous tranchez ce que nous gardons, ce que nous corrigeons et ce que nous archivons à part. Vos équipes métier fixent les règles de nettoyage : elles seules savent si deux fiches presque identiques sont un doublon ou deux clients distincts.
.Oui, et c’est l’argument principal de la reprise par lots. Tant que l’ancienne version tourne, nous y appliquons une correction urgente. La règle que nous posons dès le départ concerne les modules déjà repris : une fois qu’un module a basculé, nous portons ses évolutions dans la nouvelle version, jamais dans les deux. Sans cette discipline, vous financez deux fois le même développement et vous créez des écarts impossibles à arbitrer à la bascule finale.
.Non. L’information existe à trois endroits : le code, qui porte toutes les règles appliquées, la base de données, qui montre ce qui est rempli et ce qui reste vide, et vos équipes, qui connaissent les contournements. Nous croisons les trois. Ce qui bloque, c’est l’absence d’accès : un hébergement dont plus personne n’a les identifiants, ou un code que le prestataire refuse de rendre. Nous vous aidons à récupérer le premier, le second relève de votre contrat avec lui, et les deux passent avant le moindre chiffrage.
.Par comparaison sur de vrais dossiers, plutôt que par une relecture d’écrans. Nous sélectionnons avec vous des cas issus de votre activité, y compris les tordus que vos équipes citent de mémoire : la commande annulée puis rétablie, le dossier repris par un autre gestionnaire. Nous rejouons chacun d’eux dans les deux versions et comparons les résultats ligne à ligne. Les écarts sont de deux sortes : les régressions, à corriger, et les anciens comportements erronés que personne n’avait remarqués. Vous décidez du sort des seconds, parce que certains sont devenus des habitudes de travail.
.Nous les sollicitons à trois moments. Le relevé de l’existant, où nous les interrogeons sur ce qu’elles font de chaque écran, contournements compris. La constitution du jeu de cas de vérification, qu’elles seules peuvent fournir. Et la bascule, où le groupe pilote signale les écarts. Entre ces moments, elles poursuivent leur activité. Nous vous donnons le calendrier de ces sollicitations au démarrage, pour que vous les placiez hors de vos pics d’activité.
.Parfois oui, et nous le disons quand c’est le cas. Un outil du marché fait l’affaire tant que votre activité y trouve sa place. Si le relevé montre que l’essentiel de vos fonctions existe dans une offre du marché, l’abonnement revient moins cher qu’une reconstruction. Si vos écrans portent des règles propres à votre métier, celles que vous avez mises des années à ajuster, un éditeur ne les reproduira pas pour vous seul, et vous recommencerez à tenir des tableurs à côté. Le sur-mesure repris reste votre propriété, sans loyer récurrent.
. POUR ALLER PLUS LOIN
Où part l'argent dans une migration d'application
Vous fixez le budget au moment du relevé
Un chiffrage donné sans relevé porte sur ce que vous avez décrit, pas sur ce que l’application contient. Votre application a traversé plusieurs années, plusieurs prestataires et plusieurs demandes urgentes traitées en marge du cadre initial. Il en reste des écrans construits pour un client parti depuis, des règles de calcul ajoutées à la main dans un coin du code.
Le relevé produit une liste de fonctions, l’usage de chacune mesuré dans les données, et le coût de reprise associé. C’est ce document qui vous fait choisir entre reprendre, refaire autrement, et abandonner.
Vous chiffrez les écrans, vous découvrez les données
Nous chiffrons la reconstruction des écrans en comptant les fonctions et en découpant le travail. La reprise des données résiste à ce découpage, parce que son coût dépend de l’état de la base, que personne ne connaît avant de l’ouvrir. Un lot isolé se compte en semaines, un lot qui touche plusieurs écrans dépendants entre eux en mois : le relevé de l’existant fixe l’ordre de grandeur précis pour le vôtre, avant tout engagement chiffré. Mis bout à bout, une migration complète tient le plus souvent de l’ordre de quelques mois à un peu plus d’un an selon le nombre de lots et leurs dépendances ; le cadrage qui suit le relevé resserre cette fourchette au cas de votre application.
Quelques cas gonflent la facture. Un champ libre où vos équipes ont écrit trois informations différentes selon l’époque, qu’il faut découper en trois colonnes propres. Des dates saisies dans des formats mélangés. Un identifiant client dont la logique a changé en cours de route, ce qui casse le rattachement des dossiers anciens. Nous traitons chacun de ces cas, à condition de le trouver tôt : découvert pendant la bascule, il la stoppe net et vous renvoie à l’ancienne version.
Faire tourner l’ancienne et la nouvelle en même temps
La période de cohabitation est un poste de budget à part entière. Tant qu’elle dure, deux applications existent, et vous désignez celle qui fait autorité sur chaque donnée. Un client créé dans la nouvelle version doit-il apparaître dans l’ancienne ? Une facture émise dans l’ancienne doit-elle remonter dans la nouvelle ?
La réponse dépend du découpage, et vous la tranchez avant la première livraison. Module par module, chaque module part avec ses données et l’ancienne version cesse d’y toucher. Par groupe d’utilisateurs, les deux versions partagent la même base pendant la transition, et le travail porte sur la compatibilité des écritures. Les deux se combinent, et ce choix décide de ce que la cohabitation vous coûte. Elle vous laisse en échange la possibilité de revenir en arrière sans perdre une journée de travail.
La cohabitation pose aussi une question d’accès : tant que les deux versions tournent, chacune garde ses propres comptes, et un départ ou un changement de droit doit être répercuté le même jour dans les deux, jamais seulement dans la nouvelle. Nous tenons la même discipline sur ce qui sort vers l’extérieur : un accès fermé chez un partenaire, ou une pièce réclamée par un client ou un assureur pendant son audit, trouve la même réponse, que la demande tombe sur l’ancienne version ou sur la nouvelle.
La cohabitation ne prolonge pas indéfiniment l’exposition de l’ancienne version : nous continuons d’appliquer ses correctifs de sécurité critiques tant qu’elle reste en service, et chaque module basculé retire d’autant de terrain à un socle qui, lui, ne reçoit plus de mise à jour de son éditeur. Le jour où le dernier module la quitte, cette question ne se pose plus pour votre application.
Le périmètre que vous choisissez d’abandonner
L’économie la plus sûre porte sur ce que vous laissez derrière. Vos écrans portent des fonctions ajoutées pour un besoin ponctuel puis conservées par précaution. Le relevé mesure leur usage au lieu de le demander : les données disent quelles fonctions personne n’a ouvertes depuis longtemps.
La discussion qui suit est celle qui fait baisser la facture : vos équipes défendent ce qu’elles utilisent, et vous sortez du périmètre ce qui ne trouve pas de défenseur. Chaque fonction retirée économise sa reconstruction, sa reprise de données, sa vérification et sa maintenance future. Une application reprise plus petite que l’ancienne coûte aussi moins cher à maintenir.
Nous refaisons vos raccordements extérieurs plutôt que de les déplacer
Votre application parle à d’autres outils : comptabilité, paie, transporteur, service de paiement, messagerie, boutique en ligne. Ces liens forment la partie la plus fragile d’une migration, parce qu’ils dépendent de décisions prises ailleurs.
Vos liens les plus anciens s’appuient sur des interfaces que le prestataire extérieur a depuis remplacées. Ils fonctionnent encore par tolérance, et cette tolérance s’arrête sans préavis. Le reprendre à l’identique reviendrait à rebâtir sur la même échéance. Nous réécrivons ces liens sur les interfaces actuelles. Le chantier produit au passage la liste de tout ce que votre système appelle, avec ce que chacun attend de votre côté.
Une application qui reste la vôtre
Le code produit pendant la migration vous appartient, comme les données qu’il manipule. Vous restez libre de le remettre à l’équipe de votre choix le jour où vous changez de prestataire, sans autorisation à demander.
Ce qui ne tient pas dans le code, nous vous le livrons à part : pourquoi vous avez abandonné telle fonction, quelle règle de nettoyage nous avons appliquée à quel champ, quel écart vous avez jugé acceptable. Sans ces notes, la personne qui reprendra l’outil rétablira ce que vous veniez de retirer, en croyant bien faire. Vous gardez ces notes avec le relevé de l’existant et le jeu de cas de vérification ; c’est cette même base qui permettrait un jour de reprendre l’application dans son ensemble, mais pour l’instant elle sert d’abord à faire vivre la version que nous venons de reconstruire lot par lot.
