Des tableurs au cloud : histoire et choix des familles d'outils numériques

Cinq repères qui ont changé la manière de travailler

VisiCalc, diffusé à partir de 1979, a rendu le recalcul d'un tableau interactif sur micro-ordinateur : modifier une hypothèse permettait d'observer immédiatement ses conséquences. En 1989, le Web conçu au CERN a proposé de relier et partager des informations entre systèmes. Ces deux ruptures illustrent déjà deux besoins distincts : explorer localement et publier en réseau.

Les standards calendaires, HTTP et OpenAPI ont ensuite formalisé des échanges entre outils. Le cloud, défini par le NIST en 2011 à travers des caractéristiques et des modèles de service, décrit un mode de fourniture de ressources ; il ne transforme pas automatiquement une application en bon outil métier.

1. 1979 · Le tableur interactif

   VisiCalc automatise le recalcul et rend les scénarios accessibles sur micro-ordinateur.

2. 1989 · Le Web au CERN

   Le projet relie des documents et facilite le partage d'information entre organisations et machines.

3. 1998–2009 · Le calendrier interopérable

   iCalendar formalise des événements, dates, récurrences et identifiants échangeables.

4. 2011 · Une définition du cloud

   Le NIST distingue caractéristiques, modèles de service et modes de déploiement.

5. 2022–2025 · Des contrats d'échange mieux explicités

   La sémantique HTTP consolidée et OpenAPI 3.2 aident à décrire des interfaces, sans garantir leur qualité métier.

Distinguer fonction, modèle de données et mode d'accès

Un tableur organise des cellules et des formules ; une base gère des enregistrements, des contraintes et des requêtes ; un gestionnaire documentaire conserve des fichiers et leurs versions ; un logiciel métier représente des objets, statuts, rôles et transitions propres à une activité. Ces fonctions peuvent cohabiter dans le même produit, mais elles ne deviennent pas interchangeables.

SaaS signifie qu'une application est fournie comme un service accessible par le réseau. Ce terme ne dit rien, à lui seul, sur l'ergonomie, la portabilité, la sécurité, le fonctionnement hors ligne ou la pertinence des règles métier. De même, une application installée ou local-first peut être adaptée à un travail individuel tout en exigeant un mécanisme distinct pour collaborer.

Reconnaître le moment où un bricolage devient un système

Un bricolage n'est pas un défaut lorsqu'il est borné, compris et contrôlé. Il devient risqué quand plusieurs copies divergent, qu'une action dépend de la mémoire d'une seule personne, que les statuts sont réécrits librement ou que le reporting doit être reconstruit avant chaque décision.

À l'inverse, acheter un logiciel complet pour un tableau utilisé une fois par mois ajoute paramétrage, formation et dépendance sans bénéfice mesurable. Le seuil de changement se trouve dans le coût des erreurs, des ressaisies et de la coordination, pas dans une taille d'entreprise théorique.

• Copies concurrentes ou absence de source d'autorité.
• Erreurs répétées aux mêmes transitions.
• Droits trop larges ou impossibles à expliquer.
• Délai de décision causé par la recherche et la réconciliation.
• Départ d'une personne qui rend le processus inexploitable.

Trois cas concrets, trois progressions différentes

Pour un budget annuel personnel, un tableur sauvegardé peut suffire : les formules sont visibles et le nombre d'acteurs réduit. Pour une liste de tâches d'équipe, un registre partagé avec responsable, échéance et statut évite les versions concurrentes. Pour une opération réglementée ou composée de nombreuses exceptions, un logiciel métier peut rendre obligatoires les contrôles et conserver une trace des transitions.

La progression peut rester additive : stabiliser d'abord les colonnes et définitions, puis importer dans un registre, enfin automatiser un échange lorsque les identifiants et responsabilités sont connus. Brancher une API avant de clarifier les données accélère surtout les incohérences.

Matrice de décision avant de changer d'outil

Décrivez d'abord le processus actuel sur un exemple réel, y compris les exceptions. Classez ensuite les critères : sécurité d'une décision, temps gagné, collaboration, disponibilité hors ligne, portabilité, coût total, compétences nécessaires et délai de reprise. Une démonstration commerciale ne remplace pas une recette avec les données et rôles autorisés.

Évaluez toutes les options selon les mêmes critères, y compris le maintien de l'existant et l'application DOHM concernée. Une réponse DOHM n'est pertinente que si ses capacités publiques couvrent le besoin et si ses limites sont acceptables ; elle ne doit bénéficier d'aucun critère caché.

1. Nommer le problème, son propriétaire et l'effet attendu.
2. Cartographier données, rôles, étapes, exceptions et obligations de conservation.
3. Mesurer aujourd'hui temps, erreurs, ressaisies et incidents.
4. Comparer maintien, simplification, outil générique et outil métier avec les mêmes critères.
5. Tester le parcours critique, l'export et le mode dégradé.
6. Prévoir migration réversible, formation, responsable et date de réévaluation.

Ne connecter qu'après avoir stabilisé les responsabilités

Une interface HTTP, un fichier iCalendar ou un import CSV ne résout pas la gouvernance. Pour chaque donnée échangée, il faut une source d'autorité, un identifiant stable, une règle de conflit, une fréquence, une alerte et un mécanisme de reprise. Le guide API ou iCalendar détaille ces contrôles.

Conservez le format source et la provenance lorsque c'est nécessaire, validez le schéma avant publication et placez les données invalides en quarantaine. Les nouvelles tentatives doivent être bornées et idempotentes ; deux pollers concurrents ne doivent pas modifier la même ressource sans coordination.

• Un propriétaire par donnée et par connecteur.
• Un contrat versionné et testable.
• Une publication atomique ou un retour à la version précédente.
• Aucun secret ni donnée personnelle dans une URL publique ou un journal générique.

Checklist de migration et de continuité

Une migration réussie ne se limite pas à copier des fichiers. Elle rapproche les enregistrements, vérifie les totaux, qualifie les exceptions et permet aux personnes concernées d'accomplir le parcours réel. L'ancien système reste accessible en lecture pendant une durée décidée, sans devenir une seconde source active.

Le plan de sortie doit être essayé avant la dépendance : export exploitable, documentation des formats, restitution des droits, sauvegarde, délai et responsables. En cas d'échec critique, le retour à la version précédente doit restaurer le service sans effacer les données créées entre-temps.

• Nettoyer les référentiels et geler les identifiants avant import.
• Tester un périmètre représentatif et ses exceptions.
• Comparer volumes, contrôles et droits avant bascule.
• Former sur les décisions et erreurs, pas seulement sur les écrans.
• Mesurer après bascule le résultat utilisateur annoncé.
• Revoir le choix à date fixe et documenter la réversibilité.