Éviter une dépendance excessive envers le fournisseur du logiciel : ce qu’il faut convenir

La dépendance envers un fournisseur de logiciel ne se remarque pas tant que la relation fonctionne. Elle se découvre le jour où il faut changer quelque chose, le fournisseur, l’abonnement ou la personne qui suivait le projet, et que personne dans l’entreprise ne sait dire où sont les données, au nom de qui les services sont enregistrés et ce qu’il faut pour les faire fonctionner ailleurs. Ce n’est pas une question de confiance : c’est une question d’inventaire, et cela se fait aujourd’hui, avec un fournisseur en qui vous avez confiance.

L’objectif n’est pas de pouvoir changer de fournisseur demain. C’est que rester soit un choix, et non la seule voie possible.

L’inventaire : ce qui existe, et au nom de qui

Le premier exercice est une liste. Elle se fait une fois, se met à jour quand quelque chose change, et sert à découvrir les points où l’entreprise n’est pas propriétaire de ce qu’elle utilise tous les jours.

Les données : les exporter ne suffit pas, il faut les relations

Un export des clients dans une feuille de calcul est une liste de noms, pas votre archive. Une archive est faite de liens, et les liens sont la partie qui se perd en premier.

• Les identifiants : si les clients ont un code interne, il doit apparaître aussi dans les exports des commandes, sinon les relier de nouveau est un travail manuel.
• L’historique : états précédents, dates de modification, qui a fait quoi. Souvent, seul le dernier état est exporté.
• Les pièces jointes : contrats, photographies, documents signés. Ce sont des fichiers, pas des lignes, et ils doivent être exportés avec l’indication de ce à quoi ils étaient liés.
• Les champs calculés : totaux, échéances, scores. S’ils ne sont pas conservés, ils doivent être reconstitués en connaissant la formule, qui doit donc être écrite quelque part.
• Le format : ouvert et lisible sans le programme qui l’a généré. Une archive exportée dans un format propriétaire dépend encore du même outil.

Assistance, maintenance et évolution sont trois choses différentes

Elles doivent être appelées par trois noms différents, sinon on découvre au moment du besoin que ce qui était nécessaire n’était pas compris dans l’abonnement.

• Assistance : résoudre un dysfonctionnement. Il faut définir ce qu’est un dysfonctionnement, comment le signaler et avec quels délais de prise en charge.
• Maintenance : mises à jour des composants, sécurité, adaptations quand quelque chose change autour. Il faut définir qui décide de la faire et si elle est comprise.
• Évolution : modifications et nouvelles fonctions. Il faut définir comment elles sont estimées et qui les autorise.
• Passation : ce qui est remis, en combien de temps et sous quelle forme si la relation prend fin. C’est le point que presque personne ne met par écrit au début, c’est-à-dire quand il est facile d’en parler sans tension.

L’épreuve : un export réel, au moins une fois

Une liste de garanties jamais testées vaut peu. La vérification coûte une demi-journée et doit se faire quand tout va bien, pas quand elle devient nécessaire.

1. Demandez un export complet des données, pas un échantillon choisi par d’autres.
2. Ouvrez-le sur un ordinateur de l’entreprise, sans utiliser d’outils prêtés par le fournisseur.
3. Prenez trois cas réels et complexes, un client avec de nombreuses commandes, un dossier avec des pièces jointes, une affaire avec un long historique, et reconstituez-les à partir des fichiers. Si vous n’y arrivez pas, l’export est incomplet.
4. Essayez de restaurer une sauvegarde dans un environnement séparé. Une sauvegarde jamais restaurée est une sauvegarde dont on ne sait rien.
5. Écrivez ce qui manque et ce qui n’est pas reconstituable : cette liste est le vrai résultat de l’épreuve.

Un exemple de dossier de livraison

Illustratif, à adapter à la taille du projet. C’est la liste de ce qui devrait exister dans l’entreprise et rester à jour, indépendamment de qui le maintient.

• Liste des accès, avec le titulaire au sein de l’entreprise indiqué pour chacun.
• Adresse de l’archive du code, quand la remise est prévue par l’accord, avec les instructions pour le démarrer.
• Description de l’architecture en quelques pages : quelles parties existent et comment elles communiquent entre elles.
• Liste des composants tiers et de leurs conditions d’usage respectives.
• Procédure des sauvegardes : où elles se trouvent, à quelle fréquence, combien de temps elles sont conservées, comment on les restaure.
• Un échantillon d’export des données avec l’explication des champs.
• Les contacts opérationnels et ce qu’il faut faire en cas de blocage.

Ce que ce guide ne couvre pas

Ici, il est question de continuité technique : accès, données, documentation, tests. La propriété du code, les droits d’usage, les clauses contractuelles et les conditions de résiliation relèvent d’un autre plan et doivent être vérifiés sur le contrat et avec un conseil juridique, parce que ce qui est décrit ici comme disponible dépend d’abord de ce qui a été écrit dans l’accord. Le choix entre système de gestion standard et logiciel sur mesure, ainsi que les contrôles sur les permissions et les sauvegardes, ont des guides dédiés.