Vous avez déjà une application, et ça s’est mal passé

Prestataire disparu, projet à l’arrêt, code que plus personne n’ose toucher. C’est une situation banale et elle se rattrape presque toujours. Nous commençons par regarder ce que vous avez vraiment.

Vous reconnaissez une de ces situations ?

Ce sont les cinq raisons pour lesquelles on nous appelle. Aucune n’est irrattrapable.

  • Votre prestataire ne répond plus, ou il a fermé.
  • L’application fonctionne, mais plus personne ne sait la modifier.
  • Chaque nouvelle fonctionnalité casse quelque chose ailleurs.
  • On vous dit qu’il faut tout refaire, et vous ne savez pas si c’est vrai.
  • Vous n’êtes même pas sûr d’avoir le code entre les mains.

Comment on procède

  1. 01

    On récupère ce qui existe

    Le code, les accès, les comptes, les serveurs. C’est souvent l’étape la plus pénible et nous la prenons en charge, y compris les échanges avec votre ancien prestataire s’il est encore joignable.

  2. 02

    On regarde et on vous dit ce que ça vaut

    En une à deux semaines, nous examinons l’application en détail et nous vous remettons un état des lieux écrit dans une langue que vous comprenez : ce qui est sain, ce qui est fragile, ce qui est dangereux.

  3. 03

    On vous donne un verdict franc

    Reprendre, réparer, ou reconstruire. Nous vous disons lequel des trois, pourquoi, et ce que chacun coûterait. Il arrive que la réponse honnête soit « repartez de zéro » — nous le disons quand c’est le cas.

  4. 04

    On reprend, si vous le voulez

    Vous n’êtes pas obligé de nous confier la suite. L’état des lieux vous appartient et vous pouvez le donner à qui vous voulez.

Ce que contient l’état des lieux

Un document d’une dizaine de pages, écrit pour être lu par un dirigeant, pas par un développeur.

  • Ce que l’application fait réellement aujourd’hui, écran par écran
  • Ce qui est solide et peut être conservé tel quel
  • Ce qui est fragile et vous coûtera cher si on n’y touche pas
  • Les failles de sécurité et les données personnelles mal protégées
  • Si vous avez bien tout le code, et ce qui manque le cas échéant
  • Trois scénarios chiffrés : reprendre, réparer, reconstruire

Ce que nous vous dirons, même si ça nous coûte

  • Parfois il faut vraiment tout refaire

    Quand le coût de la remise en état dépasse celui d’une reconstruction, nous vous le disons — et nous vous montrons le calcul plutôt que de vous demander de nous croire.

  • Parfois votre ancien prestataire avait raison

    Un projet qui a dérapé n’est pas toujours la faute de l’équipe précédente. Il arrive que le périmètre ait changé dix fois. Nous ne cherchons pas un coupable, nous cherchons une sortie.

  • Parfois il ne faut rien faire du tout

    Si votre application fait le travail et que les évolutions dont vous rêvez n’apporteront rien, nous vous conseillerons de garder votre budget.

Les questions qu’on nous pose

Je ne suis pas sûr d’avoir le code. Que faire ?

C’est fréquent, et c’est la première chose que nous vérifions. Le code peut être sur un serveur auquel vous avez encore accès, chez un hébergeur que vous payez sans le savoir, ou dans un compte au nom de votre ancien prestataire. Nous vous aidons à le récupérer, et à défaut nous vous disons ce qu’il est possible de reconstruire à partir de l’application en ligne.

Mon prestataire refuse de me rendre le code. En a-t-il le droit ?

Cela dépend entièrement de ce que dit votre contrat. Si la cession des droits y figure, le code vous revient. Si le contrat est muet, la situation est plus compliquée et relève d’un conseil juridique — nous pouvons vous aider à comprendre techniquement ce qui est en jeu, mais nous ne sommes pas avocats.

Est-ce que vous refusez des reprises ?

Oui, quand la reprise ne servirait pas vos intérêts. Nous préférons vous dire non et vous expliquer pourquoi plutôt que de facturer six mois de travail sur une base condamnée.

Combien de temps avant que le projet reparte ?

L’état des lieux prend une à deux semaines. Ensuite, une reprise bien menée redonne un rythme de livraison normal en un mois environ. La première chose que nous faisons, c’est remettre en place la capacité à livrer sans rien casser.

Et si l’application est écrite dans une technologie ancienne ?

Ce n’est pas un obstacle en soi. Beaucoup d’applications anciennes fonctionnent très bien et n’ont aucun besoin d’être réécrites. La vraie question n’est pas l’âge de la technologie mais le coût de chaque évolution future — et c’est exactement ce que l’état des lieux mesure.

Le détail de l’audit technique Pour votre équipe technique — vous pouvez passer.

L’audit couvre la qualité et la lisibilité du code, l’architecture et son couplage, la couverture de tests, les dépendances obsolètes et leurs vulnérabilités connues (CVE), la reproductibilité du build et du déploiement, l’état des migrations de base de données, la gestion des secrets, la conformité RGPD des traitements, et la dette technique réellement bloquante — par opposition à celle qui est simplement inesthétique. Nous menons régulièrement des migrations Cordova et Ionic vers Flutter, des passages d’Objective-C à Swift et de Java à Kotlin, des remontées de version majeure d’Angular, de Django ou de React Native, et des reprises de projets sans historique Git exploitable.

Faisons d’abord l’état des lieux

Décrivez votre situation en quelques lignes. Nous revenons vers vous sous 24 h ouvrées pour vous dire si nous pouvons vous aider — gratuitement et sans engagement.