Tous droits réservés

Un tableur n'est pas une bonne base de données

La bureautique à l'âge de pierre

Ces temps-ci, certains pensent que l’intelligence artificielle remplacera de nombreux emplois. Pourtant, des technologies matures depuis plusieurs décennies ne sont même pas utilisées quand elles peuvent augmenter la productivité fortement. J’en donne un exemple dans ce billet et avance quelques raisons qui pourraient expliquer cet état de fait. J’en profite aussi pour râler sur les manques causés par l’inculture informatique généralisée dans les entreprises.

L’exemple en question est celui du tableur utilisé pour stocker et analyser des données complexes, alors qu’une base de données relationnelle simple serait plus efficace pour répondre au même besoin.

Que veut-on faire ?

Systems Corp. est une entreprise imaginaire qui conçoit des sous-systèmes pour ses clients, qui les intègrent dans un système global.

Les données concernent principalement des documents, identifiés par leur référence et version. Ces documents :

  • correspondent à différentes versions du système global ;
  • sont applicables dans différentes versions des sous-systèmes ;
  • l’utilisation dans un sous-système distingue l’utilisation prévue et l’utilisation effective.

Ces données peuvent :

  • être connues a priori, comme c’est le cas des documents, de leurs références et versions ainsi que de la correspondance avec une version du système global ;
  • résulter d’une analyse, comme l’utilisation dans un sous-système donné (le responsable du sous-système en décide) ou l’utilisation effective (déterminée au cours du développement).

Les besoins généraux sont :

  • de savoir quels sont les documents applicables au développement d’une version donnée d’un sous-système donné dans le cadre d’une version du système global
  • d’identifier les tâches de conception à effectuer pour une version d’un sous-système, à l’aide d’une analyse des différences par rapport à la version précédente
  • de faire la synthèse de la différence entre le planifié et l’effectif.

Ce besoin est rempli si on arrive à répondre à des questions du type :

  • quels documents sont applicables pour une version donnée du système ?
  • quels documents ont été modifiés, ajoutés ou supprimés entre deux versions du système ?
  • quels sont les documents applicables à un sous-système donné pour une version donnée du système ?
  • quels documents ont été modifiés, ajoutés ou supprimés entre deux versions d’un sous-système ?

La solution avec tableur

La solution avec tableur peut prendre différentes formes, mais en général, il s’agit de tableaux assez simples avec une tendance au gigantisme. La structure des tableaux est influencée fortement par la structure des données imposée par le client.

Pour les versions du système global, on dispose de trois tableaux plus ou moins redondants contenant des documents et leur référence :

  • un pour la première version ;
  • un pour la deuxième version ;
  • un troisième tableau avec des documents plus généraux et qui mélange des documents uniques et parfois présents dans les deux autres.

À partir de ces tableaux-là, il existe un tableau qui compare les deux premiers pour identifier les nouvelles versions des documents, mais ne permet pas d’identifier les documents qui sont nouveaux ou auraient été supprimés.

Pour savoir quels sont les documents applicables à un sous-système donné, il y a une extension d’un des tableaux précédents, mais c’est incomplet, puisque ce tableau n’est pas destiné à avoir la liste exhaustive des documents.

Si on veut comparer des versions de sous-systèmes, il faut extraire ces informations (y compris depuis un éditeur de texte qui contient des données historiques) à la main et faire des formules compliquées (voire quasi impossibles) avec Excel… puis les réimporter dans un traitement de texte puisque c’est le format des livrables officiels.

Globalement, il y a beaucoup de données présentes partout, redondées, recopiées, calculés manuellement, etc. Analyser des données et leurs relations est un job très adapté pour une base de données relationnelle !

La solution avec base de données relationnelle

Quand on analyse le problème, on se rend finalement compte qu’on a différentes entités qui sont en relation les unes avec les autres :

  • pour les entités :
    • les documents (référence, version, titre) ;
    • les versions du système global (identifiant de version) ;
    • les sous-systèmes (nom, description) et leurs versions associées ;
    • les types d’applicabilité (prévue ou effective).
  • les relations entre ses entités :
    • l’applicabilité pour une version du système global ;
    • l’applicabilité à un sous-système qui associe des documents à des sous-systèmes versionnés et possède un type.

Une fois toutes ces données saisies ou importées (notamment celles d’applicabilité qui doivent être analysées manuellement), on peut répondre avec des requêtes à toutes les questions qu’on se posait initialement.

Notamment, il est presque trivial :

  • de connaître tous les documents d’une version globale du système ;
  • de connaître les versions pour un sous-système versionné donné ;
  • de voir les documents qui ont été applicables pour une version quelconque d’un sous-système.

Avec un peu de travail de réflexion, on a accès à des informations plus intéressantes. On peut pour un sous-système comparer deux versions et voir pour chaque document :

  • s’il est nouvellement applicable ;
  • s’il a été mis à jour ;
  • s’il n’est plus applicable.

On peut aussi faire de même entre les documents dont l’applicabilité étaient prévues et ceux qui ont été effectivement appliqués.

En fonction de l’outil, ces informations sont exportables avec plus ou moins d’aisance et permettent de générer le cœur des livrables formels attendus. Il ne reste alors qu’à faire un peu de mise en forme au lieu de faire de la manipulation de données.

Pourquoi le tableur persiste pour ce genre de tâches ?

Quand les données sont au cœur de l’entreprise, on a des systèmes de base de donnée qui sont mis en place (facturation, comptabilité, logistique, clients). Pourtant, de nombreuses personnes ont des besoins pour des tâches ponctuelles et pas assez centrales pour ces grands systèmes. Ils pourraient tirer avantage de petites bases de données. Pourquoi ce n’est pas fait ?

Il y a des difficultés, il ne faut pas se leurrer. Une base de données nécessite :

  • du temps de mise en place (gagné par ailleurs, mais les coûts d’entrées peuvent être bloquants) ;
  • des compétences (identifier les bonnes entités et relations, écrire les requêtes…) ;
  • il faut que l’outil soit autorisé (Access est installé par défaut chez nous).

Mais la raison principale selon moi est que peu de gens savent que ces technologies existent et sont utilisables par le commun des mortels une fois configurées.

En fin de compte, énormément de temps est perdu sur la manipulation manuelle des données de manière très dépendante de leur format. Autrement dit, on se sert des ordinateurs comme des machines à écrire numériques, alors que ce sont des machines qui excellent dans la manipulation d’information.

Ces petites bases de données peuvent faciliter la manipulation d’information de manière fiable, systématique et rapide, ainsi que proposer une source de vérité centrale sans avoir besoin de piocher dans des dizaines de documents incohérents.

Pour que ces usages se répandent, on pourrait avoir des opérationnels avec une culture informatique : des gens qui font partie d’une équipe métier, qui ont des compétences et une culture technique relativement importante et qui sont capables d’imaginer (voire développer) les outils qui augmenteraient la productivité de leur équipe à court et moyen terme.


On parle de révolution numérique (qui est plutôt la révolution des réseaux, les ordinateurs étant très répandus depuis bien longtemps), mais les entreprises ne tirent pas partie des possibilités offertes depuis plus de 30 ans par les ordinateurs. C’est bien dommage !

Pour bien des usages, l’ordinateur est utilisé tour à tour comme :

  • une calculatrice évoluée (tableur) ;

  • une machine à écrire numérique (traitement de texte) ;

  • une bête armoire numérique (classement de tous les documents dans de simples dossiers) ;

  • des listings numériques (tableur utilisé comme base de donnée).

    On voit timidement dans des grands groupes des outils plus modernes et souples, mais ça reste généralement laborieux.

9 commentaires

Sur le forum, il y a un sujet similaire qui cherchait des alternatives à Excel pour des non développeurs. C’est difficile d’expliquer au non dev, qu’il y a ACCESS, et le temps qu’ils peuvent gagner… Surtout que le plus souvent il n’utilise pas les fonctions avancées de leurs tableaux EXCEL pour le traitement de données…

J’utilise dev/non-dev : Sachant/Ne sachant pas programmé

Les non devs ne maîtrisent pas l’aspect modèle de données/publipostage pour présenter leurs données afin de gagner du temps sur une mise en page de données à la main… Ils sont prêt à tout faire à la main. Un dev va réfléchir à l’avance comment présenter ses données, alors qu’un non dev va foncer sans réfléchir aux alternatives/outils possibles.


Les logiciels professionnels dans la gestions/administratifs sont primitifs. Il ne permettent pas un transfert/sélection facile de données entre fournisseurs/partenaires. Les métiers de gestions/administratifs manquent de standardisation des données pour envoyer des données d’un logiciel à l’autre, les données sont plusieurs fois re-transformer/re-saisie en papier/numérique/papier/numérique dans les différents niveaux/entités.


Dans le cadre de la comptabilité, s’il y aurait une standardisation et un transfert numérique (sous forme de data-model) de la facturation systématique pour les entreprises lors du paiement ou de la livraison, on pourrait supprimer 90% de la saisie comptable. Et renforcer les contrôles de pièce automatique pour détecter les fraudes.

La saisie comptable, ce n’est que re-transformé les données numériques que le fournisseurs à saisie sur son logiciel et qu’il a imprimé sur papier pour faire la facture… Une grosse perte de temps.

La saisie comptable, ce n’est que re-transformé les données numériques que le fournisseurs à saisie sur son logiciel et qu’il a imprimé sur papier pour faire la facture… Une grosse perte de temps.

Tellement. Ce que j’ai ce ne sont pas des données comptables, mais j’aime imaginer (même si j’en doute) que le client les a stockées sous une forme structurée. Si on échangeait des données au lieu d’échanger des documents, on avancerait beaucoup.

On voit d’ailleurs des technologies pour faire ça malgré tout (au lieu de traiter le problème à la racine) : OCR sur des factures ou tickets de caisse, QR codes sur de la paperasse pour faciliter le boulot des systèmes de traitement, formulaires PDF au lieu d’un formulaire en mode Web, etc.

Tellement. Ce que j’ai ce ne sont pas des données comptables, mais j’aime imaginer (même si j’en doute) que le client les a stockées sous une forme structurée. Si on échangeait des données au lieu d’échanger des documents, on avancerait beaucoup.

Pour y avoir réfléchi (j’avais hésité à faire un mémoire/projet sur une norme et d’essayer à le présenter à des concours de startup mais ça me semblait trop futuriste et l’ordre des expert-comptables n’est pas orienté vers l’évolution, elle ne supporte pas les projets qui visent à l’évolution du métier).

Pour l’utilisateur l’évolution ne serait pas si complexe que ça (les logiciels ont déjà quasiment toutes les données nécessaires). Il faudrait que les logiciels de facturation puisse permettre l’ajout de la nomenclature du type de produit, sachant que maintenant les entreprises doivent quasiment toutes passer par une caisse automatique ou un logiciel de facturation reconnu, ça serait possible de généralisé la norme.

La nomenclature du type de produit (sous forme de code?) aurait pour fonction de dire ce que c’est. Exemple pour un Peugeot utilitaire : Voiture, Utilitaire, 2016, immatriculation. Par exemple savoir, que c’est un véhicule utilitaire de 2016, va influencer la saisie d’un point de vue comptable et fiscale.

Après derrière au niveau matériel ça demanderait comme pour le système de carte bancaire/boite mail. La mise en place de méga-serveur, la sécurisation des informations, etc…

Je finis mon HS. :p


Le problème de l’OCR c’est qu’on doit scanner (ou récupérer) les factures ! Et espérer avoir toutes les factures… Alors qu’un compte en ligne faciliterait les choses… Pour moi l’OCR est une fausse solution.

+0 -0

Le problème des documents incohérents et pas à jour me touche de plein fouet au travail avec notre client actuel. On a des dizaines d’Excel différents, qui sont mis à jour manuellement, avec tout ce que ça implique d’erreurs et d’incompréhensions.

Typiquement, dans un des Excel qui décrit les caractéristiques d’un ouvrage métier, on a des feuilles de 2500 lignes, avec des références croisées, des dépendances ou valeurs par défaut à coup de code couleur incohérent, etc. On a fini par extraire les données en JSON avec un petit outil graphique d’édition, parce que ça devenait impossible de continuer comme ça.

Typiquement, dans un des Excel qui décrit les caractéristiques d’un ouvrage métier, on a des feuilles de 2500 lignes, avec des références croisées, des dépendances ou valeurs par défaut à coup de code couleur incohérent, etc. On a fini par extraire les données en JSON avec un petit outil graphique d’édition, parce que ça devenait impossible de continuer comme ça.

Ça à dû être long ! J’imagine que les données du même type suivait plusieurs formats ? (C’est horrible quand ça arrive, c’est tellement long à mettre en forme !)

Quand je dis plusieurs formats, c’est par exemple une valeur "quantité" qui se retrouve être une chaîne de caractère, par exemple :

  • 3 caisses de 100
  • 4x100
  • 400
  • 400 + 3 caisses de 100
  • 500u

Il y a beaucoup de raison pour lesquelles les entreprises utilisent les tableurs :

  • la plupart des utilisateurs n’ont pas besoin d’avoir l’ensemble des données mais uniquement une partie et utiliser la base de données peut s’avérer lourd
  • la base de données est rarement maintenue, administrée par l’entreprise. Il y donc un coup pour la licence et un nombre d’utilisateurs limités (contrairement aux tableurs qui sont souvent dans l’installation "de base" des entreprises.)
  • les différents équipes n’ont pas besoin des même informations : ils faut donc créér différents export/requêtes ce qui n’est pas donné à tous le monde alors que on pense à tort que le faire de l’analyse de données sur tableur est faisable par n’importe qui.

Typiquement, dans un des Excel qui décrit les caractéristiques d’un ouvrage métier, on a des feuilles de 2500 lignes, avec des références croisées, des dépendances ou valeurs par défaut à coup de code couleur incohérent, etc. On a fini par extraire les données en JSON avec un petit outil graphique d’édition, parce que ça devenait impossible de continuer comme ça.

Tu peux tenter d’utiliser un ETL. Le mot fait souvent peur (lourd, énorme, etc.) mais en fait, à chaque fois que j’ai été confronté exactement à ce soucis : une batterie de sources différentes (onglets différents d’une même feuille de calcul, parfois des feuilles de calculs différentes, dans différents formats, parfois du CSV, parfois tout ça à la foisà j’ai utilisé un ETL (qui ont tous un "petit outil graphique intégré") et qui pour certains t’offrent la possibilité d’écrire toi-même des transformations (genre une fonction pour dédoublonner, normaliser un nom via regex, ou carrément du scripting à la main).

Vraiment, à chaque fois, ça a été long à setup, mais une fois que ça a été mis en place, on avait un moyen vraiment sûr de convertir des données sacrément fouillies dans des tables propre dans une BDD. Ca valait le coup de se faire violence, et c’est un pattern que j’ai retrouvé chez plein de clients (note pour les gens qui font du "stream processing", Kafka Streams, Kinesis ou leurs copains, on retrouve exactement les mêmes concepts : dead-letter-queue etc. c’est super instructif).

Sinon pour le sujet en lui-même, j’ai un peu connu les deux extrêmes : du "tout en tableur" au "un SGBD + une IHM web pour tout et n’importe quoi, qui finit en extract SQL custom". Ni l’un ni l’autre ne sont agréables à maintenir pour être franc.

+1 -0

Sinon pour le sujet en lui-même, j’ai un peu connu les deux extrêmes : du "tout en tableur" au "un SGBD + une IHM web pour tout et n’importe quoi, qui finit en extract SQL custom". Ni l’un ni l’autre ne sont agréables à maintenir pour être franc.

Les extrêmes ont tendance à être… extrêmes, et donc pas forcément adaptés. Dans le peu que j’ai vu, j’ai l’impression que le tableur fait l’affaire quand les données peuvent avoir beaucoup d’attributs, mais sont assez peu en relation, mais qu’une base de donnée relationnelle devient rapidement intéressante quand tu dois exploiter de nombreuses relations.

Dans le cas décrit par le billet, on peut s’en sortir avec un tableur en vérité. C’est juste que j’anticipe de possibles extensions de la base qui augmenteront le nombre de relations. Et pour l’instant c’est en mode "Access + requêtes ad hoc", parce que c’est moi qui définit mes menus besoins.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte