Il y a un phénomène que je trouve fascinant avec SharePoint, en septembre 2009: dès qu’on le donne aux équipes, les gens se mettent à bricoler leurs propres outils. Une liste pour suivre les demandes, un petit espace pour un projet, un formulaire monté sur le coin d’une table. Pas par des développeurs — par des utilisateurs ordinaires, qui n’ont jamais écrit une ligne de code, mais qui ont un problème pis qui veulent le régler. Ce mouvement-là, on le verra nommé bien plus tard, mais il commence ici, tranquillement.

Ce qui me frappe, c’est que c’est à la fois génial pis dangereux. Génial, parce que personne ne connaît mieux le besoin que la personne qui vit le problème. Quand un utilisateur monte son propre outil, il colle parfaitement à sa réalité, sans le détour des spécifications mal comprises pis des projets qui prennent six mois. Dangereux, parce que ces outils-là naissent dans l’ombre, sans personne pour penser à la sécurité, à la sauvegarde, à ce qui arrive quand la personne qui l’a monté s’en va.

flowchart TD
    A[Utilisateur avec<br/>un probleme] --> B[Bricole son outil<br/>dans SharePoint]
    B --> C[Genial : colle<br/>au vrai besoin]
    B --> D[Risque : aucune<br/>gouvernance]
    C --> E[Adoption immediate]
    D --> F[Qui le maintient?<br/>Et s'il part?]
    F -.la vraie question.-> G[Outil orphelin<br/>dont depend l'equipe]

Le piège classique, c’est l’outil orphelin. Quelqu’un monte une liste géniale, l’équipe en devient dépendante, pis un beau jour la personne part — pis personne ne sait comment ça marche, ni comment le réparer quand ça brise. Ce qui était une solution devient un risque. Le bricolage qui sauve la journée aujourd’hui peut devenir le casse-tête de demain si personne ne se pose la question « qui s’en occupe pour de vrai? »

Comme observateur du métier, je pense que la mauvaise réaction serait d’interdire. Quand on bloque les gens, ils ne cessent pas d’avoir des besoins — ils trouvent juste des contournements encore plus cachés, pis là on perd toute visibilité. La bonne réaction, c’est d’encadrer sans étouffer: laisser les gens bricoler, mais offrir un minimum de filet. Savoir qui a monté quoi, s’assurer que les affaires importantes sont sauvegardées, avoir un plan pour quand l’auteur part. De la liberté avec des garde-fous, pas une cage.

Ce qui me plaît dans ce phénomène, c’est qu’il révèle une vérité sur les organisations: les gens veulent résoudre leurs problèmes, pis ils vont trouver un moyen avec ou sans nous. La techno qui leur donne ce pouvoir — SharePoint ici, d’autres plus tard — ne fait que rendre visible une énergie qui existait déjà. La question n’est pas de savoir si les gens vont bricoler, mais si on va les accompagner ou les laisser seuls avec les conséquences.

Ce que je retiens en septembre 2009, c’est qu’on assiste au début d’un déplacement de pouvoir: de l’informatique centrale vers les utilisateurs eux-mêmes. C’est un changement profond, pis il va prendre des années à se déployer. Mais le germe est là, dans ces petites listes pis ces formulaires montés par du monde qui voulait juste se simplifier la vie. Ce n’est pas un détail technique; c’est un avant-goût d’une autre façon de bâtir les outils.

La suite, je la regarde avec curiosité: voir comment les organisations vont composer avec cette énergie, entre le réflexe de tout verrouiller pis l’audace de faire confiance. SharePoint débarque dans les équipes, oui — mais ce qui débarque vraiment, c’est l’idée que les utilisateurs peuvent bâtir leurs propres outils. Pis ça, une fois que c’est parti, ça ne se range plus dans la boîte.