Reconstruire, quand c'est l'option la moins chère
Une refonte ne se décide pas sous la pression d'une panne. Elle se décide avec des chiffres.
Quand reconstruire ?
Quand garder l'outil en vie coûte plus cher que le remplacer.
C'est le bilan de santé qui le dit, avec vos chiffres : ce que coûte l'outil s'il reste en vie 12 mois de plus, comparé au prix d'une refonte. Tant que le premier montant est le plus bas, nous corrigeons et nous stabilisons.
Le jour où la balance s'inverse, la refonte n'est plus un pari : c'est l'option la moins chère, et vous savez pourquoi.
Vous voulez lancer un appel d'offres ? Commencez par un cahier des charges : ce que l'outil doit faire, et ce qu'il ne doit plus faire.
Comment nous reconstruisons
Trois phases, chacune chiffrée et facturée séparément.
-
Personnalisation
Nous adaptons le nouvel outil à votre façon de travailler, à partir de ce que le bilan de santé a montré.
-
Développement
Nous construisons le nouvel outil, au prix annoncé pour cette phase.
-
Livraison
Le nouvel outil est mis en service, documenté, et prend le relais de l'ancien.
Vous pouvez vous arrêter après chaque phase.
Vous avez une équipe technique ? Nous reconstruisons à ses côtés, et nous lui remettons un outil documenté qu'elle peut faire évoluer.
Ce que nous construisons
-
Applications web et mobiles
L'outil que votre équipe utilise tous les jours, dans un navigateur ou sur un téléphone.
-
API
Pour que votre outil échange ses données avec le reste, au lieu que votre équipe les recopie à la main.
-
Migrations
Quitter un framework ou une version de langage en fin de vie : AngularJS, Symfony 2, une ancienne version de PHP ou de Java, parmi d'autres.
-
Sécurité
Corriger les failles que le bilan de santé a relevées.
Une application mobile n'est pas toujours la bonne réponse : nous commençons par vérifier qu'un site responsive ne suffirait pas. Quand l'application se justifie, nous la construisons en React Native, avec l'API et le back-end qui la font tourner, et nous la publions sur l'App Store et le Google Play Store.
Questions fréquentes
Nous attendons une refonte. Pourquoi commencer par un bilan de santé ?
Justement : le bilan de santé vous dit ce que la refonte doit contenir, et ce que l'outil actuel vous coûte d'ici là. Vous décidez avec des chiffres, pas sous la pression d'une panne.
Et si l'outil peut encore tenir ?
Alors nous ne le reconstruisons pas. Nous corrigeons d'abord ce qui rapporte le plus, et nous le gardons en vie : c'est le deuxième temps, stabiliser.
Faut‑il réécrire un logiciel ?
Pas forcément, même s'il repose sur une technologie obsolète. Selon ce que montre le bilan de santé, nous pouvons le sécuriser, le mettre à jour pas à pas, ou le réécrire quand cela devient l'option la moins chère. Voir votre application repose sur une technologie obsolète.
La reprise en trois temps
Reconstruire est le troisième temps. Nous ne le proposons jamais avant un bilan de santé et un premier résultat.
-
Cadrer
En deux semaines, un bilan de santé de votre outil : ce qu'il vous coûte, ce qui va casser en premier, ce que vous pouvez économiser.
Le bilan de santé -
Stabiliser
Nous corrigeons d'abord ce qui rapporte le plus, au forfait, puis nous gardons l'outil en vie.
Stabiliser -
Reconstruire
Quand cela devient l'option la moins chère. Pas avant.
Jamais sans bilan de santé
Avant de parler refonte, nous mesurons ce que votre outil vous coûte aujourd'hui.
Pas encore prêt ? Faites l'autodiagnostic gratuit : dix questions, votre score tout de suite.