Gouverner une base comme un produit interne

La thèse de cet article, réfutable en une phrase : une base métier dont dépend une équipe mérite ce qu'on donne à un produit interne — un propriétaire, des conventions, une revue, un changelog. Si la vôtre tourne depuis trois ans sans rien de tout cela et sans incident, vous tenez un contre-exemple. Et vous avez eu de la chance.

Presque tous nos projets commencent au même endroit (données internes Ownward, 2026) :

• un fichier Excel mis à jour à la main chaque lundi ;
• un tableur utilisé comme base de données ;
• des dashboards envoyés en pièces jointes.

Des décisions s'appuient dessus chaque semaine — et personne n'en répond.

La recherche pointe dans le même sens : une revue systématique de 77 articles publiée en 2020 dans Information Technology and Control identifie les causes du shadow IT — combler les manques des systèmes officiels, délais de la DSI — et ses risques : données incohérentes, systèmes non documentés, non maintenus. Le risque ne vient pas de la technologie, mais de l'absence de responsable et de documentation.

Et le phénomène change d'échelle : fin 2022, Gartner prévoyait 80 % d'utilisateurs low-code hors DSI formelles en 2026, contre 60 % en 2021. Interdire est perdu d'avance. La gouvernance no-code réaliste commence plus bas : donner à chaque base qui compte un statut de produit.

Nous avons décrit ailleurs le programme de gouvernance à l'échelle de l'organisation. Cet article traite l'échelon en dessous : la pratique sur une base, qui s'installe en une semaine sans attendre le programme.

Premier artefact : un nom. Pas « l'équipe », pas « celui qui l'a créée et qui est parti » : une personne, inscrite dans la description de la base, qui arbitre les demandes de champs, valide les changements de structure et tient le changelog. La documentation Microsoft sur les Centers of Excellence Power Platform (mise à jour en mai 2025) en fait une recommandation explicite : propriétaires nommés, standards de nommage, accès au moindre privilège, audits réguliers.

La bonne volonté existe déjà : dans une enquête Gartner de 2021 auprès de 2 820 « business technologists », 76 % déclaraient assumer le risque de ce qu'ils construisent. Manque le cadre qui transforme cette responsabilité diffuse en rôle explicite. Trois lignes, à coller dans la description de la base :

Propriétaire : prénom.nom — arbitre structure & accès
Suppléant    : prénom.nom
Revue        : trimestrielle · changelog : table _CHANGELOG

La documentation officielle d'Airtable cadre bien la structure : une base par workflow, des vues plutôt qu'une multiplication de tables, un champ primaire « informative, unique, and short ». Mais, constat vérifié le 12 août 2026 : elle ne publie pas de convention de nommage pour les tables, champs et vues. Ce standard est laissé à l'équipe — une chance : écrivez le vôtre en une page. Le nôtre est versionné et appliqué sur plus de 30 projets livrés dans les outils de nos clients (données internes Ownward, 2026). Les principes transposables :

Adoptez ces règles ou les vôtres. Ce qui compte : qu'elles soient écrites, datées, et qu'un nouveau venu retrouve n'importe quel objet en moins d'une minute. Une convention de nommage est à une base ce que le schéma est au projet : le livrable invisible qui conditionne les autres.

L'historique de révision d'Airtable est conservé 2 semaines sur le plan gratuit, 1 an sur Team, 2 ans sur Business, 3 ans sur Enterprise Scale (constaté le 12 août 2026). C'est un bon filet pour la donnée. Pas pour la structure : le « pourquoi » d'un champ renommé ne survit pas à la rétention du plan.

L'ingénierie logicielle a réglé ce problème depuis longtemps. Keep a Changelog tient en une phrase — « Changelogs are for humans, not machines » — et six catégories : Added, Changed, Deprecated, Removed, Fixed, Security. Semantic Versioning ajoute la grammaire : un changement incompatible est majeur et s'annonce avant. Transposé à une base : renommer un champ référencé par une automatisation ou un tableau de bord est un changement majeur — il se prévient, il ne se découvre pas. Concrètement, une table _CHANGELOG dans la base elle-même :

Date       · Version · Catégorie  · Description
2026-08-03 · 2.4.0   · Added      · Champ fx_Marge sur Contrats (demande finance)
2026-07-01 · 2.3.0   · Deprecated · Vue « Ancien pipeline » — retrait au T4

Coût : une ligne par changement de structure. Valeur : le seul historique qui ne dépend ni du plan, ni de la plateforme.

Un produit interne connaît ses limites d'exploitation ; la gouvernance d'une base Airtable passe par les siennes — au 12 août 2026 : 1 000 enregistrements par base sur le plan gratuit, 50 000 sur Team, 125 000 sur Business, pièces jointes de 1 à 100 Go selon le plan. Ce ne sont pas des défauts, ce sont des paramètres. Le réflexe produit : les inscrire dans la fiche de la base avec le volume actuel, pour décider avant d'être décidé — un des principes de notre façon de construire. Le panneau d'administration centralisé arrivant avec le plan Business, en dessous, la visibilité repose sur la discipline de l'équipe.

Une base ainsi gouvernée porte bien plus que des enregistrements. Chez un client, la configuration complète d'un moteur de synchronisation reliant six CRM/ERP vit dans une base : ajouter une source, c'est ajouter un mapping, pas écrire du code (données internes Ownward, 2026). Ce niveau de confiance se construit avec les quatre artefacts de cet article.

Ce que ça coûte de ne rien faire — En 2020, près de 16 000 cas positifs de COVID ont disparu du traçage anglais : les fichiers Excel avaient atteint leur limite de lignes ; des chercheurs estiment (2021) qu'au moins 1 500 décès y sont liés (EuSpRIG). En janvier 2024, une date erronée dans un tableur a coûté environ 92 M$ au fonds souverain norvégien. Point commun : des artefacts critiques que personne ne gouvernait.

Une heure par trimestre : le propriétaire, un utilisateur clé, un regard technique si disponible. Chaque point produit au plus une action, consignée au changelog.

Ce dernier point est le plus important : une revue peut conclure que la base a dépassé son cadre. Un dashboard hebdomadaire maintenu à la main chaque lundi est ainsi devenu, chez un de nos clients, une application multi-tenant à part entière (données internes Ownward, 2026). Trajectoire normale d'un artefact qui compte.

Cette pratique ne vaut que pour les bases qui comptent. Appliquée à chaque tableur éphémère, elle devient de la bureaucratie et sera contournée — le tri est le premier acte de gouvernance. Elle repose ensuite sur la discipline : un changelog abandonné trois trimestres ment par omission, et rien ne le force nativement. Elle ne remplace pas le programme d'organisation : droits globaux, conformité et sauvegardes relèvent d'un autre échelon. Enfin, les quotas et rétentions cités, constatés le 12 août 2026, évoluent ; vérifiez-les avant toute décision d'architecture.