Sur mes mandats d’architecte-développeur, je vois SharePoint passer du gadget en démo à quelque chose qu’on déploie pour vrai chez les clients. Microsoft pousse fort: portails, collaboration, gestion documentaire, le tout intégré dans la suite. Pis cette fois, le monde l’adopte. SharePoint prend de la place pour vrai.

Comme architecte, mon rôle change face à ça. Avant, on me demandait « est-ce que ça marche? ». Maintenant on me demande « comment on structure ça pour pas que ça vire en bordel? ». Parce qu’un SharePoint laissé à lui-même, ça devient vite une jungle de sites, de sous-sites pis de documents éparpillés — exactement le désordre qu’il était censé régler.

Architecturer avant de déployer

flowchart TD
    A[Besoin client] --> B{On planifie<br/>la structure?}
    B -->|Non| C[Sites créés au hasard]
    C --> D[Jungle ingérable<br/>en 6 mois]
    B -->|Oui| E[Hiérarchie + droits<br/>+ conventions]
    E --> F[Portail qui tient<br/>dans le temps]

C’est là que mon travail d’architecte prend son sens. Avant de cliquer sur « créer », je dois penser la hiérarchie des sites, le modèle de permissions, les conventions de nommage, qui possède quoi. Sans ça, l’outil va reproduire le chaos en plus gros. La techno est puissante, mais elle pardonne pas le manque de planification.

Ce que je conseille aux clients

Mon réflexe sur les mandats: commencer petit, avec une structure claire pis une gouvernance légère, plutôt que d’ouvrir grand pis de fermer les yeux. Un portail bien pensé pour une équipe vaut mieux qu’un déploiement géant que personne contrôle. La valeur vient de la discipline, pas du nombre de fonctions activées.

Ce que j’en retiens

SharePoint qui prend de la place pour vrai, c’est une bonne nouvelle pour mon métier d’architecte: ça crée un vrai besoin de penser la structure avant l’outil. Mais c’est aussi un piège pour les clients pressés. Mon rôle, c’est de les aider à bâtir quelque chose qui tient dans le temps, pas juste une belle démo qui se transforme en cauchemar six mois plus tard.