CITÉ · Évaluer la dépendance qu'engage un outil avant de l'adopter, et garder ouverte la sortie.

Ce que cela veut dire concrètement. Avant d'installer un outil dans un collectif, écrire ce qu'il faudrait faire pour en sortir : où sont les données, dans quel format, à quel coût, et ce qui resterait du travail si le service fermait demain. Défendre les communs commence par ce calcul-là, fait avant la signature et non après.

Déléguer, ou pas

• Ce qui peut être délégué : comparer des licences, inventorier des formats, estimer un coût de migration, dresser la liste des solutions équivalentes.
• Ce qui ne doit pas l'être : arbitrer ce que le collectif accepte de perdre en autonomie contre ce qu'il gagne en confort. Cet arbitrage engage ceux qui viendront après, et qui hériteront de la dépendance sans l'avoir consentie.
• Ce qui se dégrade si on le délègue : remettre ce choix au fournisseur, ou à l'assistant qu'il fournit, revient à faire juger une partie dans sa propre cause. La question « faut-il cet outil ? » s'efface derrière « comment bien l'utiliser ? ».
• S'acquiert avec ou sans assistance : avec, pour l'analyse technique ; sans, pour l'expérience d'une dépendance subie — un changement de conditions, une donnée devenue illisible.

Comment on le voit

On propose deux outils de fonction équivalente, l'un hébergé chez un tiers, l'autre installé et administré localement. On observe si la personne pose d'elle-même la question de la sortie, et si elle nomme qui, dans dix ans, subira le choix qu'elle recommande.

La question qu'on vous pose

Qu'avez-vous perdu, concrètement, la dernière fois qu'un outil dont vous dépendiez a changé ses conditions ? Qu'est-ce qui aurait limité la casse ?