Votre application a atteint les limites de sa technologie

Elle marche. Elle a été un bon choix. Mais chaque évolution coûte plus cher que la précédente, et certaines demandes reçoivent maintenant une réponse technique là où elles attendaient une réponse métier.

Ce que vous voyez

Les délais annoncés augmentent, pour des demandes qui paraissent simples.
On vous répond de plus en plus souvent que ce n'est pas possible avec l'outil, sans que vous puissiez juger si c'est vrai.
Les performances se dégradent quand le volume monte, et on ajoute des contournements.
Un seul prestataire sait la faire évoluer, et il n'est pas remplaçable du jour au lendemain.
Plus personne n'ose annoncer une date pour la prochaine grosse évolution.

Ce qui se passe vraiment

Toute technologie a un domaine. Une plateforme qui permet de construire vite, sans écrire de code, est le bon choix pour démarrer : elle échange de la puissance contre du temps. C'est un marché honnête, et il se retourne toujours au même endroit — quand l'application devient le système central de l'entreprise, et qu'on ne lui demande plus de démarrer mais de tenir.

Le plafond ne se manifeste pas par une panne. Il se manifeste par le prix des évolutions. Chaque demande contourne une limite au lieu d'utiliser une capacité, et chaque contournement rend le suivant plus cher. On appelle cela de la dette, mais ce n'est pas de la négligence : c'est le coût normal d'un choix qui a fait son temps.

Il faut y ajouter une chose qui a changé récemment, et qui change l'arbitrage. Écrire du code sur mesure coûtait cher — c'était l'argument principal en faveur des plateformes fermées. Ce coût a nettement baissé depuis que le code s'écrit assisté, tandis que celui d'une plateforme fermée, lui, n'a pas bougé. Une décision rendue il y a quelques années sur des prix qui n'existent plus mérite d'être reprise.

Ce que ça vous coûte

Un budget d'évolution qui monte sans que le périmètre monte. Une dépendance à un prestataire unique, qui n'est pas de la mauvaise foi de sa part mais un fait : plus personne d'autre ne connaît l'assemblage. Et surtout, des sujets qu'on cesse de proposer parce qu'on connaît d'avance la réponse. C'est le plus cher des trois, et il n'apparaît sur aucune ligne comptable.

Comment on s'y prend

On ne jette pas ce qui marche. La première question du cadrage est de savoir ce qui, dans l'existant, mérite d'être gardé — et il y a presque toujours quelque chose. Sur l'une de ces reprises, le cœur de l'application était déjà écrit en code propre : seule l'enveloppe dépendait de la plateforme. La refonte ne portait donc que sur cette enveloppe, pas sur le métier, ce qui change entièrement le chiffrage.

Ensuite, on bascule par morceaux, l'ancien restant en service. Pas de grand soir : le jour du basculement, vos équipes ne découvrent pas un outil, elles en ont déjà utilisé la moitié.

Ce que vous avez à la fin

Une application dont le code vous appartient, livré sur votre propre dépôt, qu'un autre prestataire peut reprendre. Un environnement de test séparé, et une batterie de non-régression rejouée avant chaque mise en production — c'est ce qui permet d'aller vite sans casser.

Et une trajectoire écrite : ce qui a été repris, ce qui reste, et ce que coûterait la suite. Vous n'achetez pas une dépendance, vous achetez un actif.

Où nous avons déjà vu ça

Groupe international de matériaux de construction

L'application métier était arrivée aux limites de son architecture, mais son cœur tournait déjà en code propre. Le cadrage a chiffré la reprise de la seule enveloppe, et la refonte s'est engagée sans rupture de service.

Importateur de produits promotionnels sur mesure

L'outil interne, construit sans écrire de code, était devenu bloquant. Repris module par module, l'ancien restant en service jusqu'à ce que plus personne ne l'ouvre.

Les questions qu'on nous pose

Faut-il tout arrêter pendant la refonte ?

Non, et c'est la première chose que l'on vérifie. Votre outil actuel continue de tourner. On bascule un module à la fois, celui qui fait le plus mal en premier.

Comment savoir ce qui vaut la peine d'être gardé ?

C'est le travail du cadrage, et il se fait avant tout engagement. On regarde ce qui est du code, ce qui est de la configuration, et ce qui est de la donnée. Le premier se reprend, la troisième se migre — et c'est souvent la deuxième qui coûte.

Que se passe-t-il si nous voulons changer de prestataire ensuite ?

Vous le pouvez. Le code est sur votre dépôt, l'hébergement est à votre nom, et il n'y a aucune brique à nous à l'intérieur. C'est écrit au contrat, pas promis à l'oral.

Le choix d'origine était donc une erreur ?

Non. C'était souvent le bon choix au moment où il a été fait : mettre en service vite valait plus que tout le reste. Ce qui a changé, ce sont les prix relatifs. Un arbitrage se refait quand ses hypothèses ne tiennent plus, pas quand il déplaît.

Les autres situations

Dites-nous ce que votre outil ne sait plus faire.

Trente minutes suffisent pour savoir si un outil sur mesure se justifie, ce qu'il coûterait, et en combien de temps il se rembourse. Si la réponse est non, nous vous le disons aussi.

Réserver 30 minutes (nouvel onglet)