Discussion :

[mumen]

---

Je parle du tableur.

---

Je désire ici soulever un débat plutôt vaste sur une certaine limite des outils de développement de gestion, limite qui fait qu'un analyste doit plus ou moins nécessairement être aussi un développeur sous peine d'entrer dans le cycle interminable et contraignant du développement classique par un tiers. Je veux soumettre à l'attention des lecteurs développeurs du forum un procédé extrêmement simple et tout à fait générique, qui permettrait selon moi un net abaissement de cette limite dans certains cas, simplement à l'aide de l'outil tableur. Ce que je vais montrer ici est du domaine de l'intuition, puisque je n'ai implémenté ceci nulle part, et se réfère le cas échéant à votre expérience ou plus certainement à votre propre intuition.

---

Dans les faits, le tableur, qui n'est pas un logiciel de gestion de bases de données, est le premier logiciel de gestion de bases de données utilisé dans le monde. Tous les professionnels ici, qu'ils soient développeurs ou non, peuvent très bien pressentir cela.


Sur les bureaux des PC d'entreprise, il y a des icônes qui pointent vers les databases spécifiques à l'entreprise, qui sont exploitées par les utilisateurs finaux, soit à travers des progiciels paramétrés, soit plus rarement au moyen de développements à façon, soit un mix des deux. Personne dans l'entreprise sauf le développeur⁽¹⁾ ne peut intervenir sur aucune structure et encore moins en créer une qui serait pourtant précieuse, et Dieu sait que ces lacunes analytiques d'exploitation sont le quotidien de tout le monde en entreprise.


Que font les gens devant ce problème ?


Sur les bureaux, les icônes vers Access (ou toute autre solution de conception base de données) sont plus que rares. C'est logique. Quand on a créé une table avec Access, quand on a généré un formulaire, un état, on est content, on est fier. Mais quand il s'agit de partager ce travail sur d'autres postes, quand il s'agit d'enchaîner des relations, quand il s'agit de coder, de maintenir et de faire évoluer, alors commence la véritable épreuve : on se rend compte que l'on ne s'improvise pas développeur, on se rend compte que pour que le formulaire "magique" se répande durablement sur tous les postes concernés, il y a un gros investissement et que l'on rentre irrémédiablement dans le cadre du développement à façon. La logique de l'entreprise lui fait parfois penser qu'un petit développement par un stagiaire fera l'affaire, ce qui peut parfois être le cas... mais pas très longtemps, surtout quand les stagiaires défilent sur le même paquet de spaghettis, l'"enrichissant" chacun de sa propre sauce.

Par contre, sur tous les PC il y a Excel, et des tas de gens savent s'en servir. Une majorité d'utilisateurs possède des feuilles de calcul, ne contenant pas de calculs, mais des informations proprement rangées en lignes et en colonnes, avec un entête et avec l'option "filtrer" enclenchée : c'est à dire des bases de données ; locales, non typées, non relationnelles, mais des bases de données quand même.

Et puis tout naturellement dans l'entreprise, un chef de département va un jour concevoir un modèle de feuille de données, c'est-à-dire qu'il va juste mettre des libellés dans la première ligne d'une feuille, figer les panneaux, activer les filtres, colorer tout ça, etc. Ensuite, il va copier-coller ce modèle en divers point du réseau et demander à ses collaborateurs de remplir/maintenir ces feuilles au quotidien. Dans les faits, ce chef de département est ainsi devenu un véritable analyste, qui fait ce qu'il peut avec ce qu'il a pour que le travail soit fait et qui sait que pour cela, le tableur n'est si pas mal. Ce qu'il ne sait pas, ce responsable, c'est que, selon cette réflexion (première réponse à la question initiale, en anglais "Why would you want to disable them?"), il ne devrait surtout pas le faire :

Excel ne doit, en théorie, pas proliférer au-delà des postes de travail des utilisateurs.

Je ne mets ici que la citation partielle, nous verrons pourquoi.


Je fais maintenant un petit aparté sur la longueur du temps, qui va nous indiquer l'ampleur du problème. Quand j'ai débuté dans ce domaine, ne sachant pas encore que j'allais faire de la base de données mon activité professionnelle pendant les trente années et plus qui suivraient, au début de la micro-informatique (j'ai développé sur l'IBM PC à disquettes), les entreprises étaient complètement démunies face au problème de la gestion des données. C'était un travail de pro et c'était très, très cher, point barre. La première entreprise de France, les artisans, était dans l'incapacité financière complète de gérer son activité par l'informatique. C'était sans appel. Mon associé et moi avions décidé de faire quelque chose pour cela et le reste est de l'histoire personnelle. Mais la raison qui m'amène à ce point est choquante : trente ans après rien n'a changé. L'entreprise artisanale n'a pas de solution de gestion, à moins d'être très prospère et très décidée, d'avoir un C.A. qui corresponde à plus de dix salariés et, ce n'est pas la moindre des conditions, d'avoir la chance de se trouver un bon développeur, fiable et qui tienne sur la durée, parce que les logiciels tout faits, ça ne marche jamais : essayez d'acheter ou de vendre une paire de chaussures quasiment indéformables et à taille unique... le chausse-pied est rarement utile : comme ça n'entre pas, on marche sur la pointe des pieds.

Enfin, vous l'avez compris, malgré trente années sans évolution significative dans le domaine de l'informatique de gestion, quelque chose à quand même changé, une chose à changé : Multiplan est arrivé. Important changement de paradigme en son temps, il a permis en quelques années aux décideurs des entreprises de commencer à bidouiller leur propre organisation dans des feuilles éminemment locales et personnelles, qui sont vite devenues les piliers de la gestion de l'entreprise. Quand je suis devenu programmeur indépendant en 1995, mon premier nouveau client me résumait son problème, celui de sa profession entière (entreprise du bâtiment requérant un suivi de chantier), ainsi : "Nous voulons savoir si nous sommes morts maintenant, pas dans un an quand le comptable le dira". Évidemment, j'ai démarré son développement selon l'inspiration de ses feuilles Excel, sur lesquelles il avait passé des tas de fins de journées jusqu'à plus d'heures, plus des week-ends entiers, feuilles précieuses, qui commençaient à ressembler à... un tas de spaghettis.


Revenons à notre révolutionnaire décideur qui confie un modèle strict de feuille de données (et non de calcul) à ses collaborateurs. Viendra le moment où il voudra consulter les feuilles, non pas une à une, mais toutes ensemble. Voici la citation complète :

En général, c'est une décision de conception amateur que de traiter des feuilles Excel qui sont créées par l'utilisateur - elles sont trop volatiles ou imprévisibles et les solutions utilisant de telles feuilles Excel cassent plus souvent qu'elles ne fonctionnent bien. Excel ne doit, en théorie, pas proliférer au-delà des postes de travail des utilisateurs.

C'est une réflexion de bon sens. On sent le vécu et nous tous, développeurs, le partageons aussi.


Ma réflexion commence véritablement ici, sur cet inflexible point qui est pourtant un important point d'inflexion. Mon texte entre ensuite dans la réalité qui m'y a conduit.

Un client à moi a effectivement créé un modèle de feuille de données, qu'il maintient depuis sur différents chemins réseau, chacun associés à un projet. Différents collaborateurs alimentent ces feuilles en données, s'appuyant sur le verrouillage d'écriture de la feuille en réseau. Ces feuilles contiennent donc une information détaillée que mon développement ne connait pas. Ce décideur aurait pu me commanditer pour développer cette structure au sein de mon application. Mais, au-delà du coût et au-delà du délai, il sait très bien que je lui procurerais quelque chose de figé et sans doute pas aussi pratique qu'une feuille contenant, en plus de la personnalisation, des macros qui peuvent être développées à l'occasion par un bon bidouilleur de la boîte. En effet, la feuille type, en plus des données structurées, contient des colonnes plus ou moins spécifiques à un projet et donc plus ou moins mouvantes.

Nous voici dans le vif du sujet : ce client m'a fait venir pour faire exactement ce que la citation déconseille fortement de faire : il voulait une feuille récapitulative contenant la somme de toutes les feuilles réparties sur le réseau, afin de faire dessus ce que chaque feuille locale permet, c'est à dire, trier, sélectionner, lancer des macros, etc. En me commandant ce développement, il prenait implicitement en charge le point crucial du développement : la responsabilité des données dans les feuilles. Il me suffisait de bien programmer les exceptions pour satisfaire sa demande. Je n'avais pas ce jour là le recul que j'ai ici et maintenant, j'ai juste travaillé comme d'habitude : au mieux. Au bout de la journée, j'ai réalisé que j'étais revenu sur un ancien projet expérimental très amusant et passionnant, mais dans sa vérité la plus épurée. Ce qui arrive parfois, rarement, quand on travaille à l'essentiel du besoin client, c'est de voir finalement une chose nue dans sa plénitude. Cette journée de programmation là parmi tant d'autres m'a bouleversé. Ce client, je crois, ne s'est pas encore rendu compte du potentiel de ce que j'ai ainsi fabriqué, "vite fait".


Si j'écris ici, c'est pour que, si vous comprenez mon point de vue, vous me donniez le votre et, encore plus grand luxe pour moi, l'éventuel avis de vos clients, si vous en avez d'assez disponibles pour entendre et comprendre ce que peut faire un tel outil de maîtrise entre leurs mains.


Vous avez compris la situation, je la résume. Nous avons ces rôles :

• l'analyste ;
• le responsable ;
• l'opérateur ;
• le bidouilleur ;
• le développeur.

L'analyste est implicitement le responsable, mais les deux rôles sont distincts. L'opérateur est bien sûr responsable des données qu'il manipule, données que le responsable hiérarchique vérifie et valide nécessairement à chaque demande de récapitulation. Le bidouilleur est un développeur débutant qui ne sait pas organiser un projet, mais qui sait plus ou moins manipuler certains objets du développement et coder des macros : toute entreprise est susceptible d'avoir ce genre de talent plus ou moins révélé. Le développeur n'est là dans cette idée que temporairement, pour fabriquer l'outil : il est entièrement dégagé de la maintenance de ce que gère cet outil, c'est à dire des données et de leur définition... c'est le but.

Et nous avons ces étapes :

• design : une feuille modèle dessinée par un acteur de l'entreprise qui n'est ni développeur ni bidouilleur, l'analyste, avec pour toute norme des noms de colonnes en guise de déclaration d'entêtes de table de base de données. Un bidouilleur ou un développeur peuvent venir insérer des macros de présentation, d'analyse, d'impression, etc. à la feuille modèle ;
• répandre : ce modèle est réparti sur le réseau, là où les opérateurs peuvent les trouver naturellement ;
• développement : l'outil fabriqué par le développeur dépend de son site d'application. Il est renseigné sur ces différents paramètres :
  
  • le chemin réseau du modèle ;
  • la liste des chemins réseau où trouver les feuilles de données ;
  • le contenu d'au moins une colonne supplémentaire incontournable pour le récapitulatif, qui informe la ligne de sa provenance, en l'occurrence chez mon client le nom du projet ;
  • le chemin réseau du récapitulatif ;
• génération : le responsable lance un code qui lui retourne en premier lieu la validité des feuilles et en second lieu le récapitulatif demandé, qui est bien entendu une copie du modèle initial dans lequel les contenus de toutes les autres feuilles est ajouté par le code.

Cet outil a pour premier effet l'officialisation du regroupement des sources, et leur validation. C'est précisément ce qui permet de transgresser en toute sécurité l'injonction que j'ai donnée en citation. C'est cela qui est décisif, c'est cela que je veux vous faire percevoir.


Chez mon client, je n'ai fait qu'insérer ce petit développement dans la structure bien plus vaste de mon déploiement, qui contient déjà tout naturellement les paramètres requis.


Ce qui débouche de ce petit travail spécifique, c'est l'idée de développer expérimentalement ce concept de façon complètement indépendante, à travers une feuille de code d'administration des modèles, modèles aux déclarations forcément étoffées d'une page de paramètres, dans le but d'autonomiser complètement le processus. La finalité, c'est que le développeur n'ait pas à intervenir quand un acteur décide de gérer de la donnée imprévue en mono-table⁽²⁾, multi-poste et/ou multi-utilisateur, lui donnant la capacité à être ce qu'il est, un analyste, et à matérialiser lui-même ses besoins sur le réseau, ceci avec le contrôle élémentaire, nécessaire et suffisant, des paquets d'information.


Cette idée m'est littéralement tombée dessus l'autre jour. J'en ai déjà rêvé avant, c'est pourquoi j'ai pu la reconnaître. En confiant à l'analyste non programmeur plus de contrôle sur ses sources hétérogènes qui sont légion, il pourra améliorer pas mal d'organisation en entreprise, je le crois. La clef réside dans le regroupement déclaratif des ressources, c'est à dire dans un passage au niveau "méta" impliqué par un outil générique au départ très modeste, débouchant sur la fiabilisation, au départ problématique, des sources par la responsabilisation des acteurs, faisant sauter un important verrou qui permettrait de faire passer le tableur de rudimentaire à assez bon dans la gestion de bases de données⁽³⁾.

---

(1) Quand il y en a un, qui est de toute façon débordé et frémit d'anticipation à chaque intervention sur la construction qui n'est même pas nécessairement la sienne de part en part.
(2) Le relationnel est largement envisageable, mais en faisant passer ce développement à une strate supérieure de complexité déclarative pour l'analyste/le designer.
(3) En attendant que les vrais logiciels de bases de données dépassent enfin leur archaïque et autistique limite, c'est-à-dire leur incapacité crasse à communiquer sur une structure commune étendue en dissociant l'élémentaire de l'élémentaire, c'est à dire la donnée de l'interface utilisateur. C'est ce que démontre, pour ceux qui s'en souviennent ici, Nakedata.

[sevyc64]

Il ne faut pas tant taper que ça sur les tableurs pour gérer les bases de données, mais plutôt se rappeler ce qu'est (ou qu'était, il y a encore quelques années) techniquement une base de données.

Une base de données (traditionnelle, ce n'est plus trop le cas avec les NoSql, Json et autre "big data"), c'est quoi exactement. Ce n'est rien d'autre qu'une agrégation de tables avec quelques fonctions évoluées qui permettent de les lier, etc..
Une agrégation de tables ? Mais c'est alors un tableur ?

C'est exactement ça, tableur et base données (traditionnelle encore une fois), sur le plan technique, sont très similaires et intimement liés. Une base de données intègre en interne une sorte de tableur pour stocker les données.

D'ailleurs, tu cite Excel et Access pour opposer tableur et base de données. Choix plus que symbolique. Si tu es depuis si longtemps dans le métier, tu n'es pas sans savoir que pendant longtemps, et c'est peut-être toujours le cas d'ailleurs, je sais pas, Access se basait en fait sur le moteur Excel pour gérer en interne le stockage des données. Ou, dit autrement, les données d'une base Access étaient en réalité stockées dans l'équivalent d'un classeur Excel.

LA plupart des données, même encore à l'heure actuelle, organisées et hiérarchisées se conçoivent et se comprennent humainement sous la forme de tableau. Quand on a qu'un seul tableau, voire plusieurs mais sans réel lien d'interaction entre, on peut stocker ça dans un tableur, c'est tout à fait approprier. Tout le stockage de données ne nécessite pas systématiquement la mise en branle d'une base de données.
De plus le stockage de l'extraction de données d'une base se fait souvent sous forme de tableau et, la plupart du temps dans un tableur car c'est l'outil le plus naturel et le plus approprié pour cela.

Ensuite, aussi, comme tu dis, même aujourd'hui en 2016, bien que le stockage de données est une nécessité plus que jamais, la base de données n'en est pas plus accessible pour autant. Pas uniquement à cause des logiciels, c'est aussi le concept même qui n'est pas forcément à la portée de tous. C'est un concept évident pour nous développeurs qui avons la logique pour le comprendre, mais pas forcément pour d'autres personnes pas du tout informaticiennes et qui n'ont pas forcément une logique de conceptualisation des choses nécessaire à comprendre ce système.

Et il faut dire que à part Access, qui a la capacité de pouvoir en décourager plus d'un, qu'y a-t-il comme petit gestionnaire de base de données accessible et compréhensible pour Mr et Mme Michu ?
Excel reste une valeur sure, relativement simple (si on considère que 90% des utilisateurs n'utilisent et n'utiliseront jamais de 10% des capacités du logiciel), relativement compréhensible.

[Nebulix]

Cela fait du bien de revenir à la réalité après avoir été assourdi par les tambours du "big data".

[Obsidian]

Hello,

Il ne faut pas tant taper que ça sur les tableurs pour gérer les bases de données, mais plutôt se rappeler ce qu'est (ou qu'était, il y a encore quelques années) techniquement une base de données.

Une base de données (traditionnelle, ce n'est plus trop le cas avec les NoSql, Json et autre "big data"), c'est quoi exactement. Ce n'est rien d'autre qu'une agrégation de tables avec quelques fonctions évoluées qui permettent de les lier, etc..

Pas tout-à-fait, et c'est de là que vient l'ambiguïté, à mon avis. Les bases de données relationnelles sont surtout une agrégation structurée d'unités basées au départ sur le modèle des fichiers. Il est bon de rappeler qu'un « fichier », quand on ne parle pas d'informatique, c'est une boîte à fiches. Et la principale caractéristique d'une fiche, c'est d'être totalement semblable sur la forme à ses sœurs. Et c'est justement pour appliquer efficacement des traitements simples à de grandes quantités de données que les ordinateurs ont été développés, et c'est dans le tertiaire qu'ils ont été les plus utiles.

C'est aussi pour cela qu'au départ, la plupart des langages permettant de définir des champs de fichier, que ce soit le COBOL, le Basic utilisé dans les années 80 (avec PUT, GET, FIELD, RSET, LSET, etc.) et également le SQL si l'on fait exception des types à longueur variable (style VARCHAR) définissent précisément des champs de longueur fixe. Les champs de type « caractère » y étaient comblés avec des espaces (à gauche ou à droite de la donnée) et sur les systèmes les plus anciens, ils étaient faits pour refléter directement ce qui apparaissait à l'écran.

Tout ces champs concaténés formaient un « enregistrement » parce qu'ils étaient précisément, là encore, enregistrés en une seule fois, parce qu'ils n'avaient aucun sens s'ils étaient pris individuellement. Un enregistrement correspondait donc à une fiche. Physiquement, le fichier contenait donc les données brutes, concaténées les unes derrières les autres, sans aucun délimiteur ni méta-données de structure. C'est aussi ce qui définit l'interface de fread en langage C : elle s'écrit fread(buffer, taille, nombre_de_membres, fichier); parce que « taille » définit la taille d'un enregistrement et de « nombre de membres » indique le nombre de fiches à lire en une fois. Et concrètement, la bibliothèque standard du C ne fait rien d'autre que multiplier les deux paramètres et charger, dans les faits, taille×membres octets depuis le fichier vers le buffer indiqué.

Le fait que l'on puisse présenter ces données sous forme de table a une importance, bien sûr, mais ce n'est pas strictement équivalent, et c'est pour cela que c'est dangereux de faire l'amalgame. La notion fondamentale est avant tout celle du n-uplet (tuple) et c'est justement celle-là qui manque aux tableurs.

Accessoirement, on constate que les fichiers et bases de données présentent beaucoup de points communs avec les matrices. Il y a beaucoup de gens pour qui celles-ci sont naturelles alors que pour beaucoup d'autres, elles restent totalement obscures jusqu'à l'âge adulte. C'est principalement dû au fait, à mon avis, que la plupart des gens qui les enseignent les présentent souvent en disant « une matrice, c'est tout simplement un tableau de chiffres » et en embrayant sur les règles de calcul, sans expliquer à quoi correspondent ces chiffres ni à quoi cela sert de les mettre dans un tableau. Il faut une certaine dose de perspicacité pour comprendre que les lignes et les colonnes ont toute une sémantique, et que si ces lignes et colonnes peuvent être déplacées à l'intérieur de la matrice, les données qu'elles contiennent doivent toujours rester ensemble. Une grille de loto et le clavier d'un téléphone, en comparaison, sont également des chiffres dans un tableau, mais ils n'y sont que pour des raisons de présentation.

Une agrégation de tables ? Mais c'est alors un tableur ?

C'est exactement ça, tableur et base données (traditionnelle encore une fois), sur le plan technique, sont très similaires et intimement liés. Une base de données intègre en interne une sorte de tableur pour stocker les données.

Ce serait plutôt le tableur qui utiliserait une base de données en interne dans ce cas. Mais ce n'est même pas obligatoire.

D'ailleurs, tu cite Excel et Access pour opposer tableur et base de données. Choix plus que symbolique. Si tu es depuis si longtemps dans le métier, tu n'es pas sans savoir que pendant longtemps, et c'est peut-être toujours le cas d'ailleurs, je sais pas, Access se basait en fait sur le moteur Excel pour gérer en interne le stockage des données. Ou, dit autrement, les données d'une base Access étaient en réalité stockées dans l'équivalent d'un classeur Excel.

Non, les formats étaient très différents, et en réalité, Access a vu le jour après le reste des éléments du pack Office. Il se trouve simplement que tous ces outils sont faits pour communiquer entre eux, échanger des données, et qu'effectivement, quand il s'est agi de présenter les données sous forme de table à l'utilisateur, alors une bonne partie du travail avait déjà été réalisé pour le tableur. C'est normal que les composants d'une même suite s'appuient sur des objets communs.

Ensuite, un tableur est avant tout un outil permettant de créer facilement des tableaux, mais ils servent aussi et surtout à composer des feuilles de calcul. En réalité, ce sont surtout les francophones qui les appellent « tableurs ». Les anglophones appellent les documents « spreadsheet » et utilisent souvent le suffixe « calc » pour nommer les logiciels. C'est vrai avec Libre Office Calc, par exemple, c'était déjà le cas aussi avec Colorcalc sur Thomson en 1985… ;-)

LA plupart des données, même encore à l'heure actuelle, organisées et hiérarchisées se conçoivent et se comprennent humainement sous la forme de tableau. Quand on a qu'un seul tableau, voire plusieurs mais sans réel lien d'interaction entre, on peut stocker ça dans un tableur, c'est tout à fait approprier. Tout le stockage de données ne nécessite pas systématiquement la mise en branle d'une base de données. De plus le stockage de l'extraction de données d'une base se fait souvent sous forme de tableau et, la plupart du temps dans un tableur car c'est l'outil le plus naturel et le plus approprié pour cela.

Justement, le tableur est dans ce cas un super bloc-note. C'est tout-à-fait respectable et même justifié, mais c'est à mille lieues des raisons d'être des bases de données, qui sont censées garantir entre autres la cohérence, l'atomicité et l'intégrité des données qu'elles conservent (avec l'isolation, et la durabilité pour compléter ACID). Par ailleurs, une feuille de calcul est en principe statique, dans le sens où elle n'est pas faite pour accumuler des informations avec le temps. En temps normal, une cellule contient soit des données initiales, soit une formule s'appuyant sur les données tirées d'autres cellules.

Dans le même esprit, les dimensions maximum d'une feuille de calcul sont généralement limités. Aujourd'hui, Excel offre grassement 1 million de lignes environ. Il y a peu de temps, 65536 était une limite courante. C'est plus qu'il n'en faut pour une feuille de calcul mais ce n'est pas acceptable pour une base de données.

Ensuite, aussi, comme tu dis, même aujourd'hui en 2016, bien que le stockage de données est une nécessité plus que jamais, la base de données n'en est pas plus accessible pour autant. Pas uniquement à cause des logiciels, c'est aussi le concept même qui n'est pas forcément à la portée de tous. C'est un concept évident pour nous développeurs qui avons la logique pour le comprendre, mais pas forcément pour d'autres personnes pas du tout informaticiennes et qui n'ont pas forcément une logique de conceptualisation des choses nécessaire à comprendre ce système.

Et il faut dire que à part Access, qui a la capacité de pouvoir en décourager plus d'un, qu'y a-t-il comme petit gestionnaire de base de données accessible et compréhensible pour Mr et Mme Michu ?
Excel reste une valeur sure, relativement simple (si on considère que 90% des utilisateurs n'utilisent et n'utiliseront jamais de 10% des capacités du logiciel), relativement compréhensible.

C'est bien pour cela que le problème est très pernicieux : on va avoir des gens qui dans un premier temps vont se cantonner aux tableurs « parce que c'est bien suffisant pour l'usage qu'ils en font », puis vont commencer à maîtriser leur logiciel, à écrire quelques macros puis à faire des choses de plus en plus sophistiquées qui vont en fait glisser doucement vers les bases de données et là, ces mêmes personnes vont persévérer sur le logiciel qu'ils connaissent plutôt qu'utiliser un outil approprié. Ça a posé de vrais problèmes en entreprise aux informaticiens chargés de garantir la bonne exploitation de ces données, d'autant qu'administrateur de bases de données est un vrai métier.

J'ai deux anecdotes pour illustrer cela :

— Il y a 19 ans, je terminais mon service national dans une association, tout aussi nationale et d'intérêt public. Il était courant d'envoyer des mailings papiers à tous les adhérents et contacts de l'association pour leur faire parvenir différentes publications. Le système était assez bien rôdé mais la liste des noms, prénoms et adresse des contacts était maintenue dans un fichier Excel. À un moment, j'ai eu besoin d'effacer le contenu d'une cellule de la colonne « adresse ». Cela s'est fait en seulement deux clics mais pour une raison dont j'ai oublié les causes initiales, la cellule n'a pas seulement été effacée mais totalement supprimée, c'est-à-dire que toutes les cellules du dessous sont remontées d'un cran, pour prendre sa place. Toutes les cellules…*de la colonne « adresse » et uniquement celle-là ! Cela veut dire que toutes les adresses postales se sont retrouvées décalées d'une ligne par rapport aux noms de leurs propriétaires. Un moment d'inattention et ç'aurait été une campagne entière d'envois postaux qui serait revenus à l'envoyeur, plus le temps passé à identifier la panne et à ré-associer les bonnes adresses ensuite. En deux clics. Le fait même qu'un accident aussi improbable ait pu se produire dans des conditions ordinaires montre que la conception d'un modèle de données propre et l'établissement de contraintes d'intégrités dès le départ sont vitaux et doivent faire partie intégrante de la gestion d'une base de données (et que cela nécessite des outils fiables) ;

— J'ai travaillé dans les années 2000 pour un centre de recherche en génétique, remplis de gens très intelligents mais dont l'informatique n'était pas le métier, pour la plupart d'entre eux. Les plus anciens consignaient leur données dans des cahiers et ceux qui étaient plus à l'aise (la majorité) le faisaient donc dans des tableaux Excel là aussi. Dans les cas les plus bénins, cela conduisait à la sempiternelle question : « comment puis-je associer deux à deux, et horizontalement, les lignes tirées de deux tableaux distincts en fonction d'un critère commun, situé pour chacun d'eux dans une colonne propre ? » (quand les gens arrivaient à la formuler). On répondait que ça s'appelle une jointure et que c'est justement une des pierres angulaires des bases de données, et on leur donnait la solution la plus appropriée au cas par cas. Parfois, ils venaient avec un fichier texte tab-separated, ce qui facilitait les choses car la commande « join » en shell était disponible sur les serveurs Unix mis à disposition par le centre et sur lesquels ils avaient pris l'habitude de travailler.

On avait également un patron qui n'a jamais été directement désagréable avec ses salariés, mais qui aurait déclaré certaines choses telles que « l'informatique, de toutes façons, c'est vraiment pas compliqué. Il suffit de mettre le CD dans le lecteur et ça marche tout seul ». Les développeurs ont apprécié. Ça a été un certain challenge de faire comprendre que c'est justement le métier des informaticiens de concevoir le CD et (surtout) de faire en sorte qu'il marche.

Il aurait également affirmé qu'en gros, tout le métier des informaticiens du centre consistait en fait à faire des VLOOKUP() sur leurs précieux tableaux. Et VLOOKUP() est précisément le point où les tableurs finissent et les bases de données commencent. Quand on est amené à utiliser en permanence cette même fonction en contexte professionnel, c'est qu'il est temps d'apprendre « SELECT » et des rudiments de SQL. Et à défaut, commencer à envisager Access s'ils tiennent à rester à Office sous Windows.

Tout cela pour dire que tableurs et bases de données ont des utilités bien réelles, mais très différentes l'une de l'autre. Et c'est bien parce qu'ils se ressemblent de prime abord qu'il faut apprendre le plus tôt possible à ne pas les confondre.

[sevyc64]

Non, les formats étaient très différents, et en réalité, Access a vu le jour après le reste des éléments du pack Office. Il se trouve simplement que tous ces outils sont faits pour communiquer entre eux, échanger des données, et qu'effectivement, quand il s'est agi de présenter les données sous forme de table à l'utilisateur, alors une bonne partie du travail avait déjà été réalisé pour le tableur. C'est normal que les composants d'une même suite s'appuient sur des objets communs.

Au moins jusqu'à Access97, le moteur de stockage des données dans le fichier mdb était le moteur d'Excel. Il existait d'ailleurs une technique, qui à l'époque m'avait été donnée par un corp Microsoft, et qui consistait à modifier avec un éditeur hexadécimal quelques octets de l’entête du mdb et celui-ci était reconnu et ouvert par Excel comme un simple classeur. On perdait les liens, jointures, etc entre tables, les formulaires, etc.. mais on récupérait au moins les données sous forme de classeur Excel. Çà m'a permis de sauver plusieurs fois une base corrompu par une utilisation partagée et multi-utilisateur.

On avait également un patron qui n'a jamais été directement désagréable avec ses salariés, mais qui aurait déclaré certaines choses telles que « l'informatique, de toutes façons, c'est vraiment pas compliqué. Il suffit de mettre le CD dans le lecteur et ça marche tout seul ». Les développeurs ont apprécié. Ça a été un certain challenge de faire comprendre que c'est justement le métier des informaticiens de concevoir le CD et (surtout) de faire en sorte qu'il marche.

Oui, comme 99% des patrons qui ne sont pas dans un secteur d'activité informatique et comme un certains nombre aussi de ceux qui y sont.

[Obsidian]

Au moins jusqu'à Access97, le moteur de stockage des données dans le fichier mdb était le moteur d'Excel. Il existait d'ailleurs une technique, qui à l'époque m'avait été donnée par un corp Microsoft, et qui consistait à modifier avec un éditeur hexadécimal quelques octets de l’entête du mdb et celui-ci était reconnu et ouvert par Excel comme un simple classeur. On perdait les liens, jointures, etc entre tables, les formulaires, etc.. mais on récupérait au moins les données sous forme de classeur Excel. Çà m'a permis de sauver plusieurs fois une base corrompu par une utilisation partagée et multi-utilisateur.

D'accord. Tu en sais plus que moi, dans ce cas.

Je n'ai jamais été confronté à cette situation mais cela aurait été intéressant, tant sur le plan de l'assistance technique que sur la conception du produit.

Oui, comme 99% des patrons qui ne sont pas dans un secteur d'activité informatique et comme un certains nombre aussi de ceux qui y sont.

Oui, encore que c'est un peu particulier, parce que l'informatique en elle-même est particulièrement touchée par ce syndrome (même si on a tous tendance à voir midi à sa porte) et parce qu'en génétique en particulier, elle a une place prépondérante. Au moment où il aurait prononcé ces mots ou peu de temps après, on bâtissait un institut de bio-informatique flambant neuf de l'autre côté de la route. :-)

[Logan Mauzaize]

Propos très intéressant !

Difficile de réellement "répondre" puisqu'il n'y a pas vraiment de question mais plutôt un constat, une impression.
De mon expérience, je pense qu'Excel est surtout le logiciel d'analyse de données ou disons gestion de données, le plus utilisé au monde. Mais je ne le considère pas comme une base de données ou un système de gestion de base de données.

Avant de détailler mon avis sur les tableurs, je souhaite tout de même partager quelques expériences avec Excel puisque c'était tout de même l'une des tes demandes.


La première se situe exactement lors de ma première expérience professionnelle lors de ma 2e année de DUT informatique. Doit-on y voir que la problématique de traiter comme une base de données est un cas généralisé ?
Il s'agissait de développer un nouveau logiciel de gestion pour une entreprise de logistique. Il y avait un système vieillissant sous gros systèmes et VSAM (fichier séquentiel indexé) à migrer mais aussi intégrer des processus gérés pour le moment manuellement. Parmis ceux-ci il y avait toute la tarification gérée via des classeurs Excel plus ou moins standard par client mais chacune avec des particularité.
Le travail a donc été définir des macros génériques d'extraction, moyennant la mise en place d'une feuille dédiée à du paramétrage. L'extraction se faisait au format CSV pour ensuite être réintrégé sous le VSAM. Ce dernier a rapidement trouvé ces limites et lui-même a été remplacé par une base de données.

La seconde concerne une très grosse SSII, et je serai curieux de savoir si c'est toujours d'actualité. Tout le suivi et la gestion de projet passait par Excel. On remplissait différentes feuilles/classeurs soit par personne, soit pour le projet. Ces classeurs étaient alors "analysés" par une macro Excel pour générer un nouveau classeur de reporting contenant différentes métriques et indicateurs pour le projet. Les reportings de différents projets étaient eux aussi traités par une macro Excel pour former de la même manière un reporting de pôle. Et ce procédé se répétait ainsi de suite jusqu'au pilotage de l'agence.

La troisième plus récente concerne toujours le reporting d'activité. Il s'agissait de feuilles Excel pluggée à une base de données MySQL. La même feuille permettant à la fois la saisie, la consultation et la génération de rapport en fonction de profils. Cependant ce système a rapidement montré ses limites et une migration vers une application Web + ElasticSearch/Kibana a fini par faire le travail mille fois mieux !

La quatrième consiste en une gestion de planning sous Excel. Cela a été rapidement mis en place mais vraiment pas agréable en matière d'expérience utilisateur. Finalement ce système a été inclu dans une application Web dédiée à la gestion du service.


Le premier point que je souhaiterai mettre en lumière c'est que dans ce que tu décris tu opposes un classeur Excel et une application. De mon point de vue quand les classeurs commencent à devenir complexe ce sont des applications. Au même sens que les site Web dynamique sont des applications Web.
Le fait d'effectuer des traitements au sein d'un logiciel (tableur, navigateur) n'empêche pas de considérer ce en résulte comme une application. Le logiciel jouant alors le rôle de plateforme offrant des services, comme il existe les Rich Client Platform,

Devant ce fait, il devient alors évident que ceux qui créent ces "applications" sont bien des développeurs, certes avec leur expérience et connaissances restreintes, mais développeur tout de même. Et que donc la "magie" a cessé.


Ce qui me fait venir au deuxième point, ces applications souffrent des mêmes problèmes que celles développées par des stagiaires (n'y voyez aucun préjugé, c'est autant un constat qu'une évidence). Un manque cruel de conception, un code spaghetti peu commenté et difficile à lire car suivant une logique propre à la personne et au moment de l'écriture.
Ces applications ont alors du mal à vivre, non pas parce qu'elles sont limitées par Excel mais surtout limitée par la façon dont elles sont nées. Tout comme c'est le cas des applications longtemps en TMA et qui sont devenus des zones de déminage.


Si Excel est effectivement une belle plateforme gérant à la fois des données, la présentation, quelques fonctions analytiques et bien sûr du code. Cependant, il a aussi ses limites et en particulier dans l'analyse de données !
Ainsi, et je pense que beaucoup en ayant fait l'expérience partageront mon point de vue, les fonctions analytiques nécessaires notamment à l’agrégation des données collectées via différentes feuilles sont essentiellement du code VBA.

Il est donc illusoire de croire que parce cette analyse est effectuée et présentée par Excel sa modification sera aisée. C'est strictement équivalent à fournir une application sous Python ou autre. Même dans un langage compilé avec un bon process, la modification pourrait s'avérer plus simple.


Mais est-il donc possible de fournir un équivalent d'Excel, qui ne serait pas nécessairement un tableur, ayant des caractéristiques nécessaires mais offrant encore plus de puissance ?
Cela existe déjà mais il faut être conscient qu'exploiter cette "puissance" nécessite, non pas plus de compétence en développement, mais bien en analyse de données.
Car il est surtout nécessaire d'avoir une bonne abstraction des données et de leur traitement ainsi que du "pipeline" (enchaînement des transformations) pour implémenter ce que l'on souhaite et surtout en tirer de la VALEUR.


Et là on couvre le vrai domaine d'Excel mais aussi ses limites : la Business Intelligence. Car s'il me semble exagéré de dire qu'il s'agit du logiciel de base de données le plus utilisé ; il est par contre assurément le logiciel BI le plus "utilisé". Et c'est bien des compétences de Data Analyst dont il faut faire preuve.


Et ceci me fournit une transition tout idéal par un autre sujet évoqué : le Big Data. Outre l'aspect que je viens d'évoquer et qui est parfaitement adresser par le Big Data. L'aspect "variété" (l'un des différents "V", pilliers du Big Data) répond parfaitement à la problématique posé ici : l'analyse de données peu structurées.


Je souhaite également revenir sur le terme "le plus utilisé". C'est pour moi assez flou car de quoi parlons-nous ? d'instance, de table, d'enregistrement, de requête, de transaction, d'utilisateur, etc. ? Est-ce que chaque accès à une application qui repose sur une base de données est considéré comme "utilisé" ?


Concernant l'idée que tu abordes à la fin de message, j'ai le sentiment que ce n'est ni plus, ni moins qu'un formulaire Web. De nombreuses applications CMS peuvent t'offrir la même chose, exceptés que tu peux y brancher une vraie base de données et tous les traitements analytiques dont tu as besoin sans compter les problèmes de déploiement et de versionnement. Ces deux dernières problématiques n'étant absolument pas adressées dans ton exposé.
Quit éventuellement à prévoir des exports Excel pour effectuer des analyses préliminaires ou simples. Car il est vrai qu'Excel a surtout l'avantage d'être connu de tout le monde.
Mais si dans 3 expériences sur les 4 que j'ai mentionnées, Excel a été abandonné par des applications dédiées, c'est bien qu'il n'est pas la panacée.