Aller au contenu

Intégration des outils

Le tableur qui fait tourner l'entreprise, et que personne n'ose toucher.

Il contient vos règles, il gère les exceptions, et il fonctionne. Il n'a aussi ni droits, ni historique, ni test, et deux personnes savent encore lire ses formules. Comment en sortir sans casser ce qui marche.

Mis à jour le 8 août 20268 minutes de lecture

Le tableur n'est pas le problème

Commençons par écarter le mépris, qui est le réflexe habituel et le plus contre-productif.

Un tableur est un outil remarquable. Il permet à quelqu'un qui connaît le métier de modéliser une règle en quelques minutes, sans passer par personne. C'est exactement pour cette qualité qu'il finit par porter des choses qu'il ne devrait pas porter : parce qu'il était le seul moyen d'avancer, et que ça a marché.

Le fichier dont nous parlons n'est donc pas une négligence. C'est le résultat d'une série de bonnes décisions locales. Le problème n'est pas qu'il existe, c'est qu'il est devenu critique sans que personne ne l'ait décidé.

Les cinq signes qu'il l'est devenu

Un fichier est critique dès que trois de ces cinq propositions sont vraies.

  1. Son indisponibilité arrêterait une décision ou une facturation.
  2. Il contient des règles métier qui n'existent écrites nulle part ailleurs.
  3. Moins de trois personnes savent relire ses formules.
  4. Il n'a ni gestion des droits, ni historique de qui a modifié quoi.
  5. Une erreur de saisie ne déclenche aucun signal.

Les deux dernières sont les plus dangereuses, et les moins ressenties. Un tableur ne se plaint pas : une formule cassée renvoie une valeur, une plage décalée renvoie une valeur, une ligne supprimée par erreur renvoie une valeur. On ne découvre l'erreur qu'au moment où elle produit une conséquence visible, souvent plusieurs semaines plus tard.

Ce qu'il faut sauver avant de remplacer

L'erreur la plus coûteuse consiste à commander un logiciel qui « fait la même chose », puis à découvrir en cours de route que personne ne sait dire ce que le fichier fait vraiment.

Car ce fichier contient deux choses de nature très différente. Il contient un calcul, qui est facile à reproduire. Et il contient une connaissance métier (les exceptions, les cas particuliers, les corrections que quelqu'un applique de tête avant ou après) qui n'est écrite nulle part.

C'est cette seconde partie qu'il faut extraire, et elle ne s'extrait pas en lisant le fichier. Elle s'extrait en regardant travailler la personne qui l'utilise, et en lui demandant à chaque geste inhabituel : pourquoi celui-là ?

La méthode, en quatre temps

Elle vaut que vous fassiez le travail en interne ou avec quelqu'un d'autre.

  1. Filmer une utilisation réelle, du début à la fin, sans préparation. Pas une démonstration : une vraie session, avec ses hésitations.
  2. Lister chaque règle appliquée, y compris celles qui ne sont pas dans le fichier mais dans la tête de l'utilisateur.
  3. Isoler les exceptions, et pour chacune écrire ce qui la déclenche et qui décide.
  4. Seulement ensuite, décider de l'outil : un logiciel du marché, une base partagée, ou un développement.

Les trois premières étapes produisent un document utile même si vous ne remplacez jamais le fichier. Elles suppriment à elles seules le risque principal, qui n'est pas le tableur : c'est qu'une seule personne sache le faire fonctionner.

Ce qu'un remplacement doit apporter, et qui manque au tableur

Reproduire le calcul ne suffit pas. Si le nouveau système fait exactement ce que faisait le fichier, vous avez dépensé de l'argent pour changer d'interface.

Quatre choses qu'un tableur ne peut structurellement pas offrir, et qui justifient seules le remplacement.

  1. Des droits : qui peut voir, qui peut modifier, qui peut valider.
  2. Un historique : qui a changé quoi, quand, et quelle était la valeur avant.
  3. Des contrôles : une saisie hors des bornes attendues est refusée, pas enregistrée.
  4. Un comportement défini quand une donnée manque : l'écran le dit, au lieu de calculer sur ce qu'il a.

Ce dernier point est celui qui change le plus la vie quotidienne. Un tableur confronté à une donnée absente produit un résultat quand même. Un système correct s'arrête, affiche ce qui manque et depuis quand, et attend.

Garder le tableur, parfois

Le remplacement n'est pas toujours la bonne réponse, et il faut le dire.

Si le fichier sert à explorer, à simuler, à tester une hypothèse avant de décider, gardez-le. C'est ce qu'un tableur fait mieux que n'importe quel logiciel, et l'enfermer dans une application le rendrait inutilisable.

Ce qu'il faut sortir du tableur, c'est ce qui est répété, partagé et à conséquence : le calcul que quinze personnes utilisent, la règle sur laquelle on facture, le chiffre qui remonte au comité.

La frontière est là, et pas ailleurs. Un tableur d'analyse est un bon outil. Un tableur d'exploitation est une dette.