Moderniser un logiciel métier sans casser l’existant

J’ai passé huit ans sur des logiciels de ce type : dossiers hospitaliers, applications des services de secours, outils d’assurance, logiciels du secteur aéronautique. Le point commun de ces projets n’est pas la technique. C’est qu’il y avait, en face, des gens dont le travail s’arrêtait si l’outil s’arrêtait.

Cela change tout à la façon de mener le projet. Sur un site vitrine, une mauvaise soirée de mise en ligne coûte quelques visiteurs. Sur un logiciel métier, elle coûte une journée de production, et la confiance de ceux qui devront s’en servir pendant dix ans.

Trois particularités expliquent pourquoi les méthodes qui marchent ailleurs échouent ici.

Le logiciel contient des règles écrites nulle part

Après dix ans d’usage, un outil métier a absorbé des dizaines de décisions qui ne figurent dans aucun document : un cas particulier traité différemment, un seuil ajusté un jour de crise, une exception pour un client historique. Ces règles sont dans le code, et le code est la seule documentation qui n’a jamais menti.

Les contournements font partie du système

Les utilisateurs ont trouvé des chemins que personne n’avait prévus : un champ commentaire qui sert de second statut, un export vers un tableur qui alimente une réunion hebdomadaire, une astuce pour saisir plus vite. Un remplaçant qui ne prévoit pas ces usages est déclaré moins bon que l’ancien dès la première semaine — et il l’est.

On ne peut pas apprendre en public

Livrer une version incomplète et corriger ensuite est une méthode acceptable sur un produit grand public. Sur un outil interne, chaque défaut est vécu par les mêmes personnes, tous les jours, et la tolérance s’épuise vite. Ce qui est mis entre leurs mains doit fonctionner du premier coup sur leur usage courant.

La bascule d’un coup

On développe le remplaçant complet, on choisit une date, on éteint l’ancien. C’est la stratégie la plus courte sur le papier et la plus tentante : un seul effort, une seule formation, pas de période bâtarde.

Elle fonctionne à deux conditions strictes : que le périmètre soit identique à l’ancien, et qu’un retour arrière reste possible pendant plusieurs semaines. Si l’une des deux manque, c’est la stratégie qui produit les échecs dont on parle encore trois ans après.

Le module par module

On remplace une fonction à la fois. Le nouveau et l’ancien cohabitent, partagent les mêmes données, et le périmètre du nouveau grandit jusqu’à ce que l’ancien n’ait plus de raison d’exister. C’est plus long en calendrier, cela demande de faire communiquer deux systèmes — et c’est la seule approche où une erreur se rattrape sans arrêter l’activité.

C’est aussi la seule qui permette de financer le projet par tranches, et de le suspendre sans tout perdre si les priorités changent.

La façade

On garde le cœur ancien et on refait uniquement ce que voit l’utilisateur : les écrans, les parcours, l’accès depuis un téléphone. C’est rapide et peu risqué. C’est aussi une solution d’attente : la dette technique reste entière, et la question se reposera dans trois ans.

Le projet qui échoue est presque toujours le même : une bascule d’un coup, avec un périmètre élargi « puisqu’on refait tout ». On additionne alors deux risques que rien n’oblige à prendre ensemble.

Ce graphique est celui que je montre quand un devis paraît élevé au regard du nombre d’écrans. Les écrans, c’est la barre du milieu. Les trois autres existent que le projet soit chiffré ou non — la seule question est de savoir si elles sont dans le budget ou dans la surprise.

La reprise des données est le vrai chantier

Un logiciel de dix ans contient dix ans de saisie humaine : des doublons, des champs détournés de leur usage, des dates impossibles, des enregistrements que plus personne ne sait interpréter. Ces données ne se transfèrent pas, elles se traduisent — et chaque règle de traduction est une décision métier que seul le client peut trancher.

• Faites une reprise à blanc tôt, sur une copie, dès que le nouveau modèle de données est stable. Elle révèle en deux jours ce qu’aucune analyse ne trouve en trois semaines.
• Comptez les anomalies, ne les corrigez pas toutes. Certaines se règlent par du code, d’autres à la main, d’autres pas du tout : un historique ancien peut rester consultable dans l’ancien système plutôt que d’être repris à grands frais.
• Rejouez la reprise autant de fois que nécessaire. Elle doit être un script qu’on relance, jamais une opération manuelle réussie une fois — le jour de la bascule, elle tournera sur des données plus récentes.

Sur ce type de projet, les incidents de bascule viennent rarement du logiciel lui-même. Ils viennent de ce qui était branché dessus sans que personne ne l’ait noté.

• Les exports vers un tableur. Il y en a toujours, et l’un d’eux alimente un tableau de bord regardé par la direction. Changer une colonne de place suffit à le casser.
• Les impressions et les documents. Un bon de livraison, une étiquette, un courrier type : les formats sont souvent contraints par l’extérieur — un imprimeur, une administration, un transporteur.
• Les échanges avec d’autres logiciels. Comptabilité, paie, gestion commerciale, machine d’atelier. Chaque lien est un contrat implicite, et personne n’a la liste complète.
• Les habitudes de saisie. Un raccourci clavier supprimé, un ordre de champs modifié, et une saisie qui prenait trente secondes en prend cinquante. Multiplié par cent fois par jour, c’est un rejet.

C’est la semaine dont tout le monde se souviendra. Elle se prépare comme une opération, avec un ordre écrit et un plan de repli.

• Choisir le bon moment. Une période creuse de l’activité, jamais une fin de mois, jamais une veille de congés. Sur un service qui tourne en continu, la nuit du dimanche.
• Former avant, pas pendant. Deux heures par utilisateur sur le nouvel outil, avec ses propres données, une semaine avant la bascule. Une formation faite le jour même est une formation perdue.
• Désigner des référents. Deux ou trois utilisateurs formés en avance, présents le jour J. Ils absorbent l’essentiel des questions et légitiment l’outil bien mieux que le prestataire.
• Garder l’ancien accessible en lecture pendant plusieurs semaines. C’est peu coûteux, et cela transforme chaque doute en vérification de trente secondes au lieu d’un appel au support.
• Écrire le retour arrière avant d’en avoir besoin. À quelle condition on décide d’annuler, qui décide, en combien de temps on revient. Un plan de repli qu’on n’utilise pas est le meilleur investissement du projet.

Et prévoyez du temps après. Les deux semaines qui suivent une bascule concentrent des demandes d’ajustement qui ne sont pas des bugs mais des détails d’usage — et les traiter vite est ce qui décide, en pratique, si l’outil est adopté ou subi.

Si vous avez un outil interne qui tient encore mais que plus personne ne veut toucher, la première étape n’est pas un devis de développement : c’est un état des lieux — ce qu’il contient, ce qui en dépend, ce que vaut la reprise de ses données. Décrivez la situation en quelques lignes, je vous réponds sous 48 heures.