Lorsque la micro-informatique fut massivement déployée dans les entreprises, une grande question se posa : les utilisateurs allaient-ils se montrer capables d’exploiter cette puissance nouvelle et de réaliser les gains de productivité que cette technologie promettait ? Une attention toute particulière fut portée à la formation, à la documentation et à l’ergonomie. Malgré ces efforts, de nombreux déploiements se soldèrent par des difficultés, voire des échecs.
Les recherches menées sur ces déploiements firent progressivement apparaître un angle mort : la manière dont un logiciel est conçu pour être utilisé ne suffit pas à déterminer la manière dont le travail collectif sera effectivement réalisé. Les processus collaboratifs comportent des interdépendances, des ajustements et des connaissances situées qui ne peuvent être totalement anticipés.
Aux origines : le concept d’objet-frontière
Il est amusant de noter que les chercheurs qui allaient fournir un cadre particulièrement éclairant pour comprendre ce problème n’étaient pourtant ni informaticiens ni spécialistes du management. Susan Leigh Star était sociologue des sciences ; James R. Griesemer, philosophe des sciences. Et leur célèbre article de 1989, ne portait pas sur le déploiement des systèmes d’information mais sur un tout autre sujet : la création du musée de Zoologie de Berkeley.
Dans ce cadre, ils commencèrent par observer que la création du musée avait nécessité la collaboration de nombreuses personnes (administrateurs, scientifiques, donateurs, chasseurs, bénévoles…) dont les compétences, les objectifs et même la vision du projet différaient fortement. Ils établirent alors une conclusion puissante :
Des acteurs hétérogènes peuvent coopérer sans pour autant partager les mêmes buts ni les mêmes pratiques ni la même vision s’ils peuvent s’appuyer sur des artefacts communs : les objets-frontières.
Par exemple, pour les biologistes du musée, un animal naturalisé constituait un spécimen scientifique alors que pour les chasseurs, il représentait une capture.
Il en était de même pour les fiches standardisées qui permettaient de recenser les objets collectés : pour les scientifiques, ces fiches étaient des outils permettant de garantir la comparabilité des données. Mais pour les bénévoles qui devaient les remplir, ces fiches représentaient une procédure administrative.
Dans les deux cas, l’objet est le même, mais sa signification et son utilité diffèrent selon la communauté qui l’appréhende
Star et Griesemer relevèrent également une importante propriété des objets-frontières : ces artefacts sont à la fois :
- Suffisamment structurés pour constituer un support commun entre les différents acteurs ;
- Suffisamment souples pour pouvoir être interprétés et utilisés différemment selon les contextes locaux.
Si ces conditions sont réunies, alors les objets-frontières peuvent servir de supports à une collaboration sans consensus.
Ainsi, la coopération ne nécessite pas que chacun adopte exactement la représentation de l’autre. Elle nécessite simplement qu’un support commun permette de coordonner leurs actions.
Des objets qui permettent aux mondes professionnels de coopérer
Susan Leigh Star, dans des travaux ultérieurs, formalisera l’idée selon laquelle un objet-frontière ne crée pas un langage universel. Il permet à plusieurs communautés de travailler ensemble sans avoir besoin de transformer leurs propres pratiques en une pratique unique. Cette idée entraîne des conséquences importantes pour le management : une organisation peut être appréhendée comme un ensemble de communautés professionnelles, chacune disposant de connaissances et de pratiques qui lui sont propres. Ces communautés peuvent avoir des perspectives différentes tout en contribuant à des objectifs communs. Les objectifs seront alors déclinés et interprétés localement. C’est tout le sens d’une coordination sans uniformisation.
Mais alors, si les connaissances et les pratiques des communautés sont si différentes, comment peuvent-elles s’échanger de l’information ?
C’est précisément cette question des connaissances aux frontières entre communautés professionnelles que Paul Carlile va approfondir. Dans un article devenu une référence sur le sujet, il commence par préciser que dans une organisation, les frontières entre fonctions ne sont pas seulement des frontières entre personnes ou entre métiers. Elles sont aussi, justement, des frontières de connaissances.
Ainsi, pour un processus donné :
- Le métier sait comment le processus fonctionne.
- La finance sait comment il doit être valorisé.
- L’IT sait comment les données doivent être structurées.
- La conformité sait quelles contraintes doivent être respectées.
Toutes ces connaissances sont complémentaires, mais elles peuvent également être conflictuelles. Surtout, aucune de ces communautés ne possède à elle seule l’ensemble des connaissances nécessaires pour définir le processus.
Carlile distingue trois situations, correspondant à des difficultés croissantes dans le franchissement des frontières de connaissances :
- Transfert. Les connaissances peuvent être différentes, mais elles restent suffisamment compatibles pour pouvoir être transférées d’une communauté à l’autre. Il faut alors essentiellement transmettre. Par exemple, le métier explique à l’IT qu’une colonne dans un tableau correspond à un type de produit particulier.
- Traduction. Les connaissances sont différentes parce que chaque communauté possède son propre vocabulaire et ses propres contraintes. Il ne suffit alors plus de transmettre l’information : il faut la rendre intelligible dans le système de connaissances de l’autre communauté, et la transmission d’information exige alors de traduire. Par exemple, l’expression « clôture mensuelle » n’a pas nécessairement la même signification pour la comptabilité et pour le service commercial.
- Transformation. Les connaissances sont suffisamment différentes pour qu’il ne suffise plus de traduire le vocabulaire de l’un dans celui de l’autre. La confrontation fait apparaître des différences, des ambiguïtés ou des incompatibilités qui peuvent conduire les communautés à modifier leurs propres connaissances ou pratiques. Dans ce contexte, le travail collectif ne consiste plus seulement à faire circuler une spécification existante. Il consiste à construire progressivement une compréhension commune du processus.
Ainsi, avec Star et Griesemer, le concept d’objet-frontière permet de comprendre comment des communautés différentes peuvent coopérer. Avec Carlile, la question se déplace : lorsque ces communautés détiennent des connaissances interdépendantes, l’objet-frontière devient aussi un support de transfert, de traduction et, parfois, de transformation des connaissances.
Mais concrètement, quels objets peuvent permettre cette traduction et cette transformation des connaissances ? Dans de nombreuses organisations, cet objet existe déjà. Il peut prendre une forme étonnamment banale : un classeur Excel.
Excel, un objet-frontière en pratique
A la lumière de ce que nous avons vu, il apparait clairement que les fichiers tableurs type Excel possèdent la plupart des propriétés requises pour supporter la collaboration en entreprise, y compris entre des communautés d’utilisateurs fortement hétérogènes.
Pour le montrer, nous utiliserons le cas rapporté par Eugenia Cacciatori dans son article Memory objects in project environments: Storing, retrieving and adapting learning in project-based firms
Ce cas est localisé dans une grande entreprise britannique de construction, organisée autour de projets et intervenant à la fois dans le bâtiment et les infrastructures.
Le point de départ de Cacciatori est la question du transfert des apprentissages entre projets : comment une organisation évite-t-elle de repartir de zéro à chaque projet, alors que les équipes, les configurations de projet et les contextes changent continuellement ?
Elle observe alors qu’un objet apparemment banal — un classeur Excel — concentre et fait circuler une part importante des savoirs nécessaires à la préparation des offres. Ce classeur sert à construire collectivement, pendant les appels d’offres, une estimation de coût de cycle de vie d’un bâtiment.
Un support commun à plusieurs communautés
Plusieurs catégories d’utilisateurs vont manipuler ce fichier, mais leurs usages sont différents :
- Les ingénieurs y saisissent des éléments liés à la conception, aux solutions techniques et aux caractéristiques du bâtiment
- Les spécialistes des coûts transforment ces éléments en structures de chiffrage et en estimations
- Les responsables d’exploitation ajoutent les conséquences futures en matière de fonctionnement, d’entretien ou de renouvellement
- L’équipe commerciale utilise le résultat pour formuler une proposition économiquement cohérente au client.
Tous ces utilisateurs manipulent le même fichier, mais chacun y projette ses propres préoccupations. Par exemple, une formule, une colonne ou une nomenclature peuvent devenir le support concret d’une négociation entre communautés. On voit donc que le rôle du classeur ne se limite pas à la transmission des données : il matérialise, organise et archive les arbitrages entre différentes formes de connaissance.
Un objet suffisamment structuré pour permettre la coordination…
Ce processus basé sur un tableur partagé fonctionne parce qu’il transforme un problème distribué (ici, évaluer le coût de cycle de vie d’un bâtiment dans le cadre d’une offre) en une série d’éléments visibles, calculables et discutables.
Il fournit notamment :
- Une même trame de calcul et de présentation pour les estimations,
- Des catégories qui stabilisent les éléments à considérer dans le chiffrage ;
- Un historique de données et hypothèses provenant d’expériences antérieures ;
Tout cela représente à la fois une représentation commune permettant de rapprocher conception, coût de construction, exploitation et maintenance mais aussi, très concrètement, un support matériel sur lequel les désaccords deviennent explicites et peuvent être traités.
Cette stabilité est importante dans une entreprise qui fonctionne par projets : les équipes se recomposent, les personnes ne partagent pas toujours les mêmes habitudes, et le projet précédent est souvent terminé lorsque le suivant commence. Le classeur crée donc un point de référence durable. Il conserve suffisamment de traces pour que des personnes n’ayant pas participé au projet antérieur puissent reprendre une partie du raisonnement au lieu de repartir entièrement de leur propre mémoire ou de leurs fichiers individuels. Cacciatori montre ainsi que les classeurs Excel peuvent être à la fois des objets-frontières entre métiers et des dispositifs de mémoire entre projets.
…Et suffisamment flexible pour permettre l’adaptation
Le tableur permet de stocker des données, mais il n’est pas une base de données au sens du système d’information. Il n’impose pas une vérité unique et définitive sur les coûts. Et s’il permet la coordination, c’est aussi parce que les utilisateurs peuvent adapter ce qui y a été mémorisé dans le contexte de l’appel d’offres en cours. C’est ce mécanisme que les chercheurs désignent sous le nom d’adaptation locale.
Dans le cas de cette entreprise de construction, le classeur Excel fait partie d’une routine de réponse aux appels d’offres, mais les utilisateurs ne se limitent pas à y saisir des valeurs dans des cellules prévues à l’avance comme le ferait un formulaire basique. Ils peuvent reconfigurer sa représentation du problème, afin que le modèle de coûts de cycle de vie corresponde au bâtiment, au client et aux compromis propres au projet en cours.
Chaque nouveau projet pourrait ainsi modifier les choix architecturaux et techniques, mais aussi les exigences du client, les conditions d’exploitation ou encore les contraintes de prix, de calendrier, de risque et de concurrence.
Les valeurs, formules et structures provenant d’un projet antérieur n’ont donc pas vocation à être simplement réemployés tels quels. Ils deviennent plutôt des points de départ : on les consulte, on en discute la pertinence, on les corrige, on ajoute des éléments ou l’on reconfigure les hypothèses. C’est cette possibilité d’appropriation locale qui évite que la mémoire ne devienne une simple reproduction du passé.
Par exemple, une discussion entre métier et finance peut conduire à modifier une règle. Cette règle est incorporée dans le classeur, sous forme de formules et/ou de mises en forme conditionnelles, puis le nouveau fonctionnement est testé par les utilisateurs.
Dès lors, le classeur Excel n’est plus seulement le support du processus : il est également le support de sa construction.
On comprend donc dans que dans ce type de contexte, la souplesse de l’outil n’est pas une défaillance du système. Elle peut être précisément ce qui permet au processus de fonctionner dans des situations que sa conception initiale n’avait pas prévues. Autrement dit, c’est la possibilité d’adaptation locale qui permet au classeur Excel d’être un support efficace du travail réel, dans la durée.
De l’objet-frontière à l’objet-mémoire
Dans le cadre d’un processus d’entreprise, Excel peut donc agir comme un objet-frontière : un artefact capable d’évoluer pour répondre aux besoins locaux de différents groupes, tout en conservant une structure commune qui permet à ces groupes de se coordonner.
Cette évolution se poursuit au fil du temps, et elle révèle ainsi une autre propriété, parfois moins visible : le classeur Excel peut également devenir un support de mémoire organisationnelle.
La mémoire organisationnelle n’est pas une simple base d’archives
Une organisation ne mémorise pas seulement dans des bases de données ou des documents explicitement conçus pour conserver des connaissances. Elle mémorise également dans ses routines, ses procédures, ses outils, ses documents de travail et, plus largement, dans tous les objets qui conservent les traces de son expérience.
Barbara Levitt et James March ont décrit l’apprentissage organisationnel comme un processus par lequel les organisations incorporent les enseignements de leur histoire dans des routines qui orientent leur comportement. Ces routines permettent ensuite à l’organisation de conserver une partie des enseignements du passé malgré le départ des personnes qui les ont acquis.
James Walsh et Gerardo Ungson prolongeront cette réflexion en proposant de considérer la mémoire organisationnelle comme l’ensemble des mécanismes permettant à une organisation d’acquérir, de conserver et de retrouver de l’information. La mémoire d’une organisation n’est donc pas nécessairement localisée dans un « lieu » unique : elle peut être distribuée entre plusieurs supports et plusieurs niveaux de l’organisation.
Cette distinction est importante pour comprendre le rôle particulier d’Excel.
Au fil des itérations par lesquelles les utilisateurs font évoluer un classeur Excel, ils y entreposent évidemment des valeurs, des formules, des hypothèses, des nomenclatures ou des règles de calcul. Mais peu à peu, le classeur va permettre de conserver une représentation du problème tel qu’il a été compris et traité par les équipes. Et là encore, cette mémoire n’aura pas pour but de figer la connaissance, mais de soutenir son évolution.
Se souvenir ne signifie pas reproduire
C’est précisément ce que met en évidence Eugenia Cacciatori dans son étude de l’entreprise de construction britannique.
Les autres dispositifs de mémoire étudiés dans l’entreprise (manuels, procédures de conception…) avaient principalement pour objectif de conserver des connaissances considérées comme relativement stables. Ils pouvaient évidemment être mis à jour, mais leur vocation première était de transmettre des règles applicables d’un projet à l’autre. Cacciatori les décrit ainsi comme une forme relativement statique de mémoire.
Le classeur Excel étudié joue un rôle différent. Son objectif n’est pas de définir la seule bonne manière de construire un bâtiment, mais plutôt d’archiver la façon dont les différents services de l’entreprise ont représenté le projet de construction et les arbitrages qu’ils ont rendu. A partir de cette représentation, les responsables du prochain projet pourront alors évaluer ce qui demeure pertinent.
La mémoire devient ainsi une ressource pour l’action, et non une archive destinée uniquement à conserver le passé.
C’est un point essentiel dans les environnements où les situations se renouvellent rapidement. Une mémoire parfaitement fidèle mais impossible à adapter serait peu utile. À l’inverse, une adaptation permanente sans conservation de l’expérience conduirait l’organisation à recommencer continuellement le même travail.
Cacciatori montre que le classeur Excel étudié permet cette articulation en combinant des catégories relativement stables avec la possibilité de les recombiner afin de représenter des configurations différentes d’un projet à l’autre. Le classeur constitue ainsi un point de connexion entre plusieurs mémoires distribuées : celles des individus, des métiers, des unités organisationnelles et des projets précédents.
Le classeur conserve donc aussi l’histoire du processus
Cette propriété permet de mieux appréhender certains classeurs Excel, dont la complexité peut sembler correspondre à une accumulation anarchique.
En réalité, lorsqu’un utilisateur ajoute une colonne, crée une feuille, introduit une formule, modifie une règle de calcul ou ajoute un contrôle, il ne se contente pas d’enrichir un fichier. Souvent, il y incorpore une réponse construite collectivement face à un problème rencontré dans le travail réel.
Une première version du classeur peut correspondre à une première compréhension du besoin, puis survient une exception. Le modèle est alors adapté, puis l’environnement évolue et révèle une limite de la structure précédente : une nouvelle adaptation est alors discutée puis ajoutée.
Au fil du temps, le classeur va devenir l’archive sédimentée d’une succession d’apprentissages.
Ce phénomène rejoint la conception de l’apprentissage organisationnel proposée par Levitt et March : l’organisation apprend lorsque l’expérience modifie les routines qui orientent son action. Or ces routines ne sont pas nécessairement uniquement écrites dans des procédures formelles. Elles peuvent être incorporées dans des outils et des représentations utilisés quotidiennement.
Une mémoire limitée, mais précieuse
Cacciatori montre comment un classeur Excel devient progressivement un support de la mémoire organisationnelle de l’entreprise. Mais cette mémoire ne doit pas être considérée comme une photographie fidèle du passé.
En effet, même en prenant en compte les fonctionnalités d’archivage automatique, un classeur ne conserve pas nécessairement l’histoire complète des décisions qui ont conduit à son état actuel. Il ne permet pas toujours de savoir pourquoi une colonne a été ajoutée ou pourquoi une formule a été créée.
Cette mémoire est donc sélective et reconstruite : elle conserve ce que les utilisateurs ont progressivement incorporé dans la représentation du processus, mais pas nécessairement le raisonnement complet qui a accompagné cette construction.
C’est précisément pour cette raison que la mémoire du classeur reste liée aux personnes et aux échanges qui l’entourent.
Cacciatori montre que le classeur Excel ne remplace pas la participation des professionnels : il la facilite. Il relie les connaissances incorporées dans l’artefact à l’expertise détenue par les individus et permet de remettre cette expertise en discussion dans le contexte d’un nouveau projet. Autrement dit, l’objet-mémoire ne remplace pas la mémoire humaine : il lui sert de point d’appui.
Une personne qui reprend un ancien classeur ne récupère donc pas mécaniquement la connaissance de son prédécesseur. Elle récupère une représentation sur laquelle elle peut s’appuyer pour reconstruire une partie de cette connaissance, l’interroger et l’adapter.
Cela permet de comprendre pourquoi un classeur Excel ancien peut parfois être extrêmement précieux alors même que personne ne sait exactement qui l’a construit : c’est parce qu’il contient une partie de ce que l’organisation a appris.
De la mémoire du processus à la mémoire du travail réel
Nous pouvons maintenant relier les deux concepts qui structurent cet article.
L’objet-frontière permet de franchir une frontière entre des communautés professionnelles : il donne à des acteurs différents un support suffisamment commun pour coordonner leurs actions, tout en leur permettant de conserver leurs propres manières de comprendre et de traiter le problème.
L’objet-mémoire franchit une autre frontière : celle du temps. Il permet à une expérience passée de devenir une ressource pour une situation future.
Et dans le cas du classeur Excel, ces deux fonctions sont étroitement liées.
- Parce qu’il permet à plusieurs métiers de confronter leurs connaissances, le classeur conserve les résultats de cette confrontation.
- Parce qu’il conserve ces résultats, il peut ensuite être repris par d’autres personnes ou dans un autre projet.
- Parce qu’il peut être modifié, les utilisateurs suivants peuvent à leur tour enrichir ou corriger ce qui avait été construit auparavant.
On peut alors décrire le processus d’évolution du classeur Excel sous forme de cycle :
Dans ce contexte, un classeur Excel n’est donc ni simplement un document, ni simplement un outil de calcul : Il est le support matériel dans lequel l’organisation conserve une partie de la manière dont elle a appris à faire son travail.
Et de notre expérience, c’est précisément l’une des raisons pour lesquelles certains classeurs Excel deviennent si difficiles à remplacer. Car on ne peut pas les réduire aux données qu’ils contiennent ou aux calculs qu’ils réalisent. Leur valeur réside dans ce que ces données, ces calculs et ces représentations permettent de comprendre du processus, et de le faire évoluer.
Et c’est précisément ce qui pose une difficulté particulière aux projets de transformation des systèmes d’information : remplacer le fichier ne consiste pas nécessairement à remplacer un outil. Il s’agit de remplacer un objet dans lequel une partie de l’organisation a progressivement inscrit sa mémoire du travail.
Excel apparaît alors sous un jour différent.
S’il est parfois utilisé pour contourner les limites d’un système d’information, ce n’est pas seulement parce qu’il serait « plus simple » ou « plus pratique ». C’est aussi et surtout parce que sa souplesse lui permet de devenir, au fil du temps, un support de coordination, d’adaptation et de mémoire.
Si elle veut limiter le risque d’une résurgence du Shadow IT, l’organisation ne doit pas tenter de supprimer les classeurs Excel avant d’avoir compris ce que l’organisation y a progressivement construit.
De l’objet-mémoire au système d’information : le rôle de Gathering Tools
Les développements précédents permettent de comprendre pourquoi la relation entre Excel et les systèmes d’information est plus complexe qu’une simple opposition entre un outil « bureautique » et un outil « professionnel ».
Lorsqu’un classeur devient à la fois objet-frontière et objet-mémoire, le remplacer ne consiste pas simplement à reproduire ses calculs dans une application.
Il faut également préserver une capacité essentielle : celle de faire évoluer le processus lorsque la situation de travail évolue.
C’est précisément là que se situe la difficulté de nombreux projets de transformation.
Formaliser sans figer
Un système d’information est naturellement conçu pour apporter de la stabilité.
Les données doivent être structurées, les règles explicites, les droits définis, les traitements reproductibles. Cette formalisation est indispensable pour garantir la qualité des données, la sécurité, la traçabilité et l’interopérabilité.
Mais un processus métier réel ne se résume pas à ce qui peut être défini à l’avance.
De nouvelles situations apparaissent. Une règle doit être interprétée. Une information jusque-là considérée comme secondaire devient nécessaire. Un indicateur doit être calculé différemment. Une étape de validation doit être ajoutée. Une organisation évolue.
Le risque est alors de considérer toute adaptation locale comme une anomalie à éliminer.
Or les travaux de Star, Griesemer, Carlile et Cacciatori conduisent à une lecture différente : une partie de cette capacité d’adaptation peut être constitutive du fonctionnement de l’organisation.
Dès lors, le défi pour l’organisation consiste à permettre que cette adaptation s’exerce sans perdre les garanties apportées par le système d’information.
C’est précisément l’espace dans lequel se situe Gathering Tools
Gathering Tools part d’un constat simple : entre le processus entièrement formalisé dans le système d’information et le travail laissé à des fichiers Excel individuels, il existe un espace important, et c’est précisément dans cet espace que se développent de nombreux classeurs métiers.
Ils permettent aux utilisateurs de représenter leur problème, de faire évoluer leurs règles, de coordonner plusieurs intervenants et de conserver progressivement les adaptations produites par l’organisation.
Mais cette souplesse a un coût lorsque le classeur reste isolé du système d’information. Ce coût est une somme de risques : risque de duplication de données, de divergence des règles et de dépendances fragiles.
C’est pourquoi, lorsqu’un processus devient critique, l’organisation peut se retrouver face à un choix difficile : accepter les risques liés au classeur ou lancer un projet de développement pour reconstruire dans une application ce qui avait progressivement été construit par les utilisateurs.
Gathering Tools propose une troisième voie.
Plutôt que de demander aux utilisateurs de renoncer à la représentation du processus qu’ils ont construite, Gathering Tools propose de transformer cette représentation en une application métier gouvernée, tout en conservant une partie de la souplesse qui avait rendu le classeur utile.
Conserver l’intelligence du classeur sans conserver ses fragilités
Si le classeur Excel est devenu à la fois un objet-frontière, qui permet à plusieurs communautés professionnelles de travailler ensemble, et un objet-mémoire, qui conserve une partie des apprentissages successifs de l’organisation, alors le remplacer ne devrait pas signifier faire disparaître ces deux fonctions.
C’est précisément sur cette distinction que repose l’approche de Gathering Tools.
Dans un projet Gathering Tools, le classeur Excel construit par les métiers devient d’abord le cahier des charges du frontend de l’application. Il constitue une représentation concrète du processus tel que les utilisateurs l’ont construit et tel qu’ils ont besoin de le voir fonctionner. La promesse de Gathering Tools est de reproduire fidèlement l’apparence du document Excel ainsi que les fonctionnalités qu’il met en œuvre sans plus utiliser la technologie d’Excel. Le métier n’a donc plus à se demander si telle présentation, telle formule ou telle interaction pourra être reproduite dans l’application : si elle peut être réalisée dans Excel, Gathering Tools s’attache à la reproduire de manière similaire dans l’application.
Lorsque l’application est mise en production, le classeur Excel n’est, techniquement, plus utilisé. Mais il n’est pas supprimé du projet pour autant :
- il conserve sa fonction d’objet-frontière : il reste un support compréhensible par les différentes communautés qui participent au processus et permet de continuer à travailler sur sa représentation sans devoir traduire chaque évolution en spécifications informatiques abstraites.
- Il conserve également sa fonction d’objet-mémoire : il demeure la représentation de référence d’un processus construit progressivement par l’organisation, avec ses règles, ses choix et ses apprentissages.
Cette propriété devient particulièrement importante lorsque le travail réel évolue. Un nouveau besoin apparaît, une règle métier change, une nouvelle catégorie de données devient nécessaire ou une organisation modifie son fonctionnement. Les utilisateurs peuvent alors faire évoluer le classeur Excel, comme ils l’ont toujours fait. Le nouveau classeur constitue à la fois la nouvelle expression du travail réel et la nouvelle étape de sa mémoire. Gathering Tools peut ensuite reprendre ces modifications et les implémenter de manière robuste dans l’application. La mémoire n’est donc pas figée au moment de la transformation initiale : elle peut continuer à évoluer.
Mais l’intérêt de cette approche ne se limite pas à la conception et à l’évolution du processus. Gathering Tools permet également de préserver, dans le travail quotidien, une part de la capacité d’adaptation locale qui caractérise l’objet-frontière.
Une entité chargée de fournir des données peut ainsi exporter son document Gathering Tools au format Excel et travailler à partir de ce document. Elle retrouve alors un espace dans lequel elle peut saisir, simuler, créer des liens, copier-coller des éléments, insérer ou supprimer des lignes et des colonnes, voire modifier une partie de la structure pour répondre à sa situation particulière.
Le fichier Excel devient alors temporairement un espace local d’adaptation. Mais contrairement à un échange de fichiers classique, cette adaptation ne modifie pas directement le système de référence. Pour transmettre ses données, l’utilisateur doit réimporter le classeur dans son document Gathering Tools. Grâce à un balisage spécifique réalisé lors de l’export, Gathering Tools peut retrouver les emplacements correspondant aux données attendues et réinjecter les valeurs au bon endroit, y compris lorsque l’utilisateur a modifié la structure du classeur.
C’est lors de cette réintégration que le processus retrouve son cadre gouverné : les règles de gestion, les contrôles de cohérence et les règles de complétude s’appliquent, et les données peuvent alors être transmises au système d’information.
Cette architecture permet ainsi de séparer sans les opposer les deux dimensions que le classeur Excel réunissait historiquement.
- Le classeur Excel reste un objet-frontière parce qu’il permet aux utilisateurs de communautés différentes de représenter, discuter et adapter leur manière de travailler.
- Il reste un objet-mémoire parce que cette représentation peut évoluer dans le temps tout en conservant la continuité du processus.
- Gathering Tools prend en charge ce que le fichier ne peut garantir durablement : l’intégrité des données, les règles de gestion, les droits, la complétude, la traçabilité et l’intégration au système d’information.
Gathering Tools ne cherche donc pas à « tuer Excel ». Il le remplace pour la transaction, mais le préserve pour ce qui fait sa force : sa capacité à servir d’objet-frontière et d’objet-mémoire, c’est-à-dire à faire travailler ensemble des communautés différentes et à permettre au travail réel de continuer à évoluer.