Aller au contenu
oråke
oråke
Faire l'autodiagnostic Prendre rendez‑vous

Reprendre une application que plus personne ne maintient

Votre équipe n'a plus le temps, votre développeur est parti, votre prestataire ne répond plus ? Voici comment reprendre la main.

Faire l'autodiagnostic gratuit → 20 minutes pour savoir si nous pouvons vous aider

Une reprise d'application existante, c'est reprendre en charge une application que plus personne ne maintient : récupérer ses accès, son code et son hébergement, et les remettre à votre nom. Elle se fait en trois temps : cadrer, avec un bilan de santé en deux semaines ; stabiliser, en corrigeant d'abord ce qui rapporte le plus ; reconstruire, seulement quand c'est l'option la moins chère.

Les signes

Six questions. Si l'une d'elles reste sans réponse, votre application tourne encore, mais plus personne ne la tient vraiment.

  • La personne clé

    Si la personne qui connaît votre outil part demain, qui le répare, et en combien de temps ?

  • Le réencodage

    Combien d'heures par semaine votre équipe passe‑t‑elle à recopier des données entre votre outil et le reste ?

  • Les demandes perdues

    Sur cent demandes qui arrivent par votre site, combien atterrissent vraiment chez quelqu'un qui les traite ?

  • La dernière panne

    La dernière fois que l'outil a planté, qui avez‑vous appelé, et combien de temps ça a duré ?

  • Le code introuvable

    Personne ne sait où est le code. S'il fallait le confier demain à un autre développeur, qui saurait quoi lui envoyer ?

  • L'hébergement qui n'est pas à vous

    L'hébergement est au nom de l'ancien prestataire. Que se passe‑t‑il le jour où il cesse de payer la facture ?

Pour faire le point en dix questions, avec votre score tout de suite : l'autodiagnostic.

Votre équipe est là, mais n'a plus le temps de s'en occuper ? Votre prestataire ne répond plus ? Trouvez votre situation.

Ce que « reprendre » veut dire

Reprendre une application, ce n'est pas seulement relire du code. C'est récupérer tout ce qui la fait tourner, et le remettre à votre nom.

  • Les accès

    Les comptes administrateur de l'application, du serveur, de la base de données et des services tiers : qui les détient, et qui peut encore s'en servir.

  • Le code source

    Le code complet, dans la version qui tourne vraiment en production, rangé dans un dépôt auquel votre entreprise a accès.

  • L'hébergement

    Le serveur ou le service cloud, avec son compte et sa facture : à quel nom, payé par qui, et ce qui se passe si le paiement s'arrête.

  • Les noms de domaine

    Le domaine de votre site et de vos e‑mails : chez quel registrar, au nom de qui, et quand il doit être renouvelé.

  • La documentation

    Comment l'outil s'installe, se sauvegarde et se met à jour. Souvent, rien de tout cela n'est écrit : c'est le moment de l'écrire.

  • La sécurité

    Les mises à jour en retard, les mots de passe partagés, les comptes d'anciens collaborateurs encore actifs, les sauvegardes jamais testées.

Cette semaine, sécurisez

La plupart de ces points demandent quelques e‑mails, pas un développeur. Ils vous protègent, que vous fassiez appel à nous ou non.

  • Les accès administrateur. Listez chaque compte : l'application, le serveur, la base de données, la messagerie, les services tiers. Pour chacun, notez qui le détient. Un accès critique doit être connu d'au moins deux personnes de votre entreprise, et rangé dans un gestionnaire de mots de passe partagé.
  • Les anciens accès. Fermez les comptes des personnes qui ne travaillent plus sur l'outil, en commençant par leurs accès personnels. Les mots de passe que l'application utilise elle-même se changent avec quelqu'un qui sait où ils sont configurés, sinon c'est la panne.
  • Le code source. Demandez où il se trouve (GitLab, GitHub, Bitbucket, le serveur, l'ordinateur de quelqu'un) et obtenez un accès au nom de votre entreprise. Vérifiez que c'est bien la version qui tourne en production.
  • L'hébergement. Qui paie le serveur, à quel nom est le compte, sur quelle carte ? S'il est au nom d'un tiers, demandez au minimum un accès administrateur, puis le transfert du compte.
  • Le nom de domaine. Retrouvez le registrar, le titulaire et la date de renouvellement. Le titulaire doit être votre entreprise. Inscrivez la date dans votre agenda, un mois avant : un domaine expiré coupe le site et, souvent, les e‑mails. Notez aussi qui gère les DNS, les réglages qui dirigent le site et les e‑mails vers le bon serveur.
  • Les sauvegardes. Existent‑elles, où sont‑elles stockées, et quand quelqu'un a‑t‑il essayé d'en restaurer une pour la dernière fois ? Une sauvegarde jamais restaurée est un espoir, pas une sauvegarde. Gardez-en une copie récente hors de l'hébergement.
  • Les licences et abonnements. Licences logicielles, API, envoi d'e‑mails, certificats : listez ce dont l'outil dépend, qui le paie et à quel nom. Un abonnement payé par quelqu'un d'autre s'arrête avec lui.
  • Les applications mobiles. Le code et les comptes développeur App Store et Google Play doivent être au nom de votre entreprise, pas d'un développeur.
  • Le contrat. Retrouvez le contrat, les devis signés et les conditions générales : à qui appartient le code, et ce qui est prévu à la fin de la collaboration. En cas de doute, posez la question à un juriste.
  • Une page. Rassemblez tout cela sur une seule page, rangée là où quelqu'un d'autre que vous la retrouvera.

Des cases restent vides ? C'est par là que commence un bilan de santé : nous récupérons ce qui manque avant de toucher à quoi que ce soit.

Comment nous reprenons

La reprise en trois temps : cadrer, stabiliser, reconstruire. Jamais à l'aveugle, et jamais la refonte en premier.

  1. 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é

  2. Stabiliser

    Nous corrigeons d'abord ce qui rapporte le plus, au forfait, puis nous gardons l'outil en vie.

    Stabiliser

  3. Reconstruire

    Quand cela devient l'option la moins chère. Pas avant.

    Reconstruire

D'abord, le bilan de santé

Tout commence par le bilan de santé, en deux semaines : une heure avec la direction, une heure avec les personnes qui utilisent l'outil tous les jours, et la lecture du code et de l'hébergement. Vous n'avez pas le code source ? Nous commençons par là : le récupérer fait partie du bilan.

Vous recevez un bilan écrit : ce que l'outil vous coûte, ce qui va casser en premier, ce que vous pouvez économiser, et ce qui se passe si rien ne change dans 12 mois. Il se termine par trois propositions chiffrées : le correctif urgent, le module rentable, et la refonte, estimée mais pas proposée.

Moins de 3 000 € HTVA Prix fixe annoncé après un premier échange de 20 minutes. Demander un bilan de santé

Et l'ancien prestataire ?

À ménager plutôt qu'à accuser.

Celui qui a construit l'outil sait des choses qu'aucun code ne dit : pourquoi tel choix a été fait, quel serveur fait quoi, quelle tâche tourne la nuit. S'il est parti, c'est souvent pour des raisons ordinaires : un autre emploi, un autre client, la retraite, un compte devenu trop petit pour sa société.

Quand c'est possible, nous travaillons avec lui. Une courte passation, préparée avec des questions précises, épargne des jours de recherche. Et une demande courtoise obtient plus qu'un reproche : les accès, le code, une sauvegarde, un moment pour répondre aux questions. Proposer de rémunérer ce temps aide souvent.

Il ne répond plus du tout ? Lisez que faire quand votre prestataire informatique ne répond plus.

Quelle est votre situation ?

Questions fréquentes

Combien de temps prend une reprise d'application ?

Le premier temps, le bilan de santé, prend deux semaines. La suite dépend de ce qu'il montre et de ce que vous décidez : rien n'est obligatoire après le bilan, et chaque étape est chiffrée avant de commencer.

Notre ancien prestataire refuse de nous donner le code. Que faire ?

Ne résiliez ni l'hébergement ni le contrat avant d'avoir récupéré le code, les données et les accès. Envoyez une demande écrite et précise, avec une date, et gardez-en une trace ; si rien ne bouge, un juriste vous dira ce que prévoit votre contrat. Le bilan de santé part alors de ce dont vous disposez : vos accès, le serveur, la base de données, ce qui reste du code. Le détail : votre prestataire informatique ne répond plus.

Faut‑il tout réécrire pour reprendre une application ?

Pas forcément, et jamais en premier. Nous corrigeons d'abord ce qui rapporte le plus, puis nous gardons l'outil en vie : c'est le deuxième temps, stabiliser. La refonte ne vient que le jour où garder l'outil en vie coûte plus cher que le remplacer.

Combien coûte une reprise d'application ?

Le bilan de santé coûte moins de 3 000 € HTVA, à prix fixe annoncé après un premier échange de 20 minutes. Chaque étape suivante a aussi son prix fixe, annoncé avant de commencer. Vous décidez ensuite, les prix sous les yeux.

Par où commencer ?

Faire l'autodiagnostic → 20 minutes pour savoir si nous pouvons vous aider