Logiciel métier abandonné

Votre développeur ne répond plus. Et maintenant ?

L'outil qui fait tourner votre activité a été développé il y a des années. Depuis, plus personne ne s'en occupe. Voici les risques réels que vous courez, les quatre vérifications à faire dès maintenant, et ce qu'il est encore possible de sauver.

Les signes qui ne trompent pas.

Un logiciel métier ne s'arrête pas du jour au lendemain. Il se dégrade, et les signaux d'alerte passent souvent inaperçus jusqu'à l'incident.

Silence

Les demandes restent sans réponse

Vos e-mails mettent des semaines à obtenir une réponse, quand ils en obtiennent une. Les corrections promises n'arrivent jamais, et vous avez appris à contourner les bugs plutôt qu'à les signaler.

Blocage

Plus aucune évolution n'est possible

Vous avez renoncé à demander une modification, parce qu'on vous répond que « ce n'est pas prévu » ou que le devis est disproportionné. Votre outil ne suit plus votre activité, c'est votre activité qui s'adapte à l'outil.

Opacité

Personne ne sait comment ça marche

Le développeur d'origine est parti, a cessé son activité ou a changé de métier. Il n'existe aucune documentation, et plus personne dans votre entreprise ne sait ce qu'il y a sous le capot.

Sécurité

Le serveur n'est plus à jour

Le système d'exploitation qui héberge votre application n'a plus reçu de correctif depuis des années. Chaque mois qui passe ajoute des failles connues et non corrigées.

Pourquoi c'est un risque, et pas seulement un inconfort.

Un logiciel métier abandonné concentre trois risques distincts, qui ne se manifestent pas au même moment.

Le risque de sécurité est le plus sournois. Une application web qui tourne sur un système obsolète accumule des vulnérabilités publiquement documentées. Elle contient souvent des données personnelles de vos clients ou de vos salariés, ce qui vous expose au titre du RGPD, en tant que responsable de traitement.

Le risque de continuité est le plus brutal. Le jour où le serveur tombe, où l'hébergement expire ou où une mise à jour casse quelque chose, personne n'est en mesure d'intervenir. Votre activité s'arrête, et vous découvrez que vous ne savez même pas qui appeler.

Le risque de captivité est le plus coûteux à long terme. Sans le code source, sans les accès et sans documentation, vous ne pouvez ni changer de prestataire ni faire évoluer l'outil. Vous êtes dépendant d'une personne qui ne répond plus.

Ce qu'il faut faire, dans cet ordre.

Avant même de chercher un nouveau prestataire, quatre vérifications déterminent vos marges de manœuvre.

Étape 1

Vérifier qui possède le code

C'est la question la plus importante, et la plus souvent négligée. En droit français, l'auteur d'un logiciel en reste titulaire tant qu'aucune cession écrite n'a été signée. Relisez votre contrat : s'il ne mentionne aucune cession de droits, le code ne vous appartient probablement pas, même si vous l'avez financé.

Étape 2

Récupérer une copie complète

Le code source, la base de données, les fichiers déposés par les utilisateurs, et les accès au serveur. Demandez-les par écrit, même si la relation est tendue. Sans cette copie, aucune reprise n'est possible.

Étape 3

Faire l'inventaire de l'existant

Quelle technologie, quelle version, où est-ce hébergé, quel nom de domaine, quels certificats, quelles dépendances externes. C'est ce diagnostic qui détermine si une reprise est simple ou coûteuse.

Étape 4

Sauvegarder avant toute chose

Avant qu'un incident ne survienne, avant même de chercher un repreneur. Une copie de la base et des fichiers, conservée chez vous. C'est la seule chose irremplaçable.

Ce qui peut être repris, et ce qui ne peut pas.

Reprise généralement possible

  • Applications web (PHP, Python, Node.js, Ruby) hébergées sur un serveur
  • Bases de données MySQL, MariaDB, PostgreSQL
  • Outils construits sur des socles ouverts comme Dolibarr, WordPress, Symfony ou Laravel
  • Intranets, extranets, espaces clients et portails de gestion
  • Applications dont vous possédez le code, même sans documentation

Reprise impossible ou déconseillée

  • Logiciels installés sur poste (.exe) dont vous n'avez pas les sources
  • Progiciels du marché type Sage, EBP ou Cegid, qui relèvent de leur éditeur
  • Applications mobiles natives iOS et Android
  • Tout logiciel dont vous n'êtes pas propriétaire et dont l'auteur refuse la cession
  • Développements dont le coût de reprise dépasserait celui d'une reconstruction

Et si le développeur refuse de coopérer ?

C'est une situation fréquente, et elle n'est pas bloquante dans la plupart des cas.

Si vous disposez déjà d'un accès administrateur à votre application ou à votre serveur, une copie complète peut souvent être réalisée sans son concours. Si l'hébergement est à votre nom, vous en gardez le contrôle même en cas de rupture.

En revanche, si tout est au nom du prestataire, hébergement compris, votre situation est plus délicate et mérite un conseil juridique avant toute démarche. Nous vous dirons franchement dans quel cas vous vous trouvez, sans vous vendre une prestation impossible.

Dans tous les cas, nous n'intervenons jamais sans votre autorisation écrite et nous ne contournons aucun accès. Notre travail commence par un état des lieux honnête.

Une méthode sans interruption de service.

Une reprise se fait toujours sur une copie. Votre application en production continue de tourner pendant que nous travaillons, et vous ne basculez qu'une fois que tout a été vérifié.

Nous commençons par un audit qui vous dit ce que vaut l'existant, ce qui est réparable et ce qui ne l'est pas. Vous recevez un rapport écrit qui vous appartient, que vous soyez ensuite client ou non.

Pour aller plus loin, voyez comment se déroule une reprise de logiciel métier, ou ce qu'il faut prévoir pour récupérer un logiciel hébergé chez votre prestataire.

Questions fréquentes.

Mon prestataire ne répond plus, ai-je le droit de faire intervenir quelqu'un d'autre ?

Cela dépend de la propriété du code. Si votre contrat prévoit une cession de droits à votre profit, vous êtes libre. Sans cession écrite, l'auteur reste titulaire de ses droits, même si vous avez financé le développement. C'est la première chose à vérifier, et nous le faisons avec vous avant toute intervention.

Combien de temps prend la reprise d'un logiciel existant ?

L'audit initial prend une à deux semaines selon la taille de l'application. La reprise effective dépend de l'état du code et de la documentation disponible, en général de quelques semaines à quelques mois. L'audit vous donne une estimation ferme avant tout engagement.

Faut-il tout reconstruire ?

Rarement. Dans la majorité des cas, l'application fonctionne, elle a simplement été laissée sans maintenance. Remettre à jour le socle technique, corriger les failles et documenter le code coûte bien moins cher qu'une reconstruction. Nous ne recommandons une reconstruction que lorsqu'elle est réellement moins coûteuse.

Que se passe-t-il si je ne fais rien ?

L'application continuera de fonctionner, jusqu'au jour où elle s'arrêtera. Le déclencheur est généralement une panne du serveur, une expiration d'hébergement ou une intrusion. Le problème n'est pas que ça tombe, c'est que personne ne saura le relever.

Intervenez-vous en dehors du Tarn ?

Oui. Une reprise applicative se fait à distance, sur le serveur et sur le code. Nous accompagnons des entreprises partout en France. Les déplacements sur site sont réservés aux besoins d'infogérance de proximité, autour de Castres.

Serai-je propriétaire de ce que vous produisez ?

Oui, intégralement. Le code que nous écrivons, la documentation, les accès et l'hébergement sont à votre nom. C'est un principe que nous appliquons sans exception, et il figure dans nos conditions.

Faisons le point sur votre logiciel, sans engagement.

Un premier échange gratuit pour comprendre votre situation et vous dire franchement ce qui est possible.