Prenons une liste SharePoint très simple : cinq colonnes, deux vues et un formulaire remplacent des demandes éparpillées dans les courriels. Techniquement, c’est déjà une petite application. Le formulaire valide et écrit un élément; les vues exécutent des filtres; les permissions déterminent qui lit; un workflow peut modifier l’état et envoyer une alerte.

formulaire -> liste Demandes -> workflow -> tâche + courriel
                 |                |
                 |                `-> règle de changement d'état
                 `-> vues, recherche et export

Le bricolage reste près du besoin et permet d’essayer vite. Je ne le ridiculiserais pas. S’il existe, c’est souvent qu’un processus réel n’a pas trouvé de place ailleurs. Le risque apparaît lorsque l’usage change sans que les opérations suivent.

Supposons les colonnes suivantes :

Numéro, Demandeur, Catégorie, Responsable, Statut, DateCréation

Au départ, Statut est un choix libre. Une vue affiche Statut <> Fermée. Puis une personne ajoute Terminé, une autre écrit Complete, et les demandes disparaissent de vues différentes. Un vocabulaire contrôlé et une machine à états deviennent nécessaires dès que le statut pilote du travail.

Le seuil où le prototype devient un service

Je regarderais cinq signaux :

1. plusieurs personnes en dépendent chaque jour;
2. son arrêt bloque une activité ou un engagement client;
3. la liste contient de l’information personnelle ou financière;
4. un workflow, une macro ou une intégration agit sans surveillance;
5. l’auteur unique n’est plus disponible pour le soutenir.

Un seul signal sérieux suffit pour nommer un propriétaire et une classe de service. Cela ne signifie pas réécrire immédiatement en .NET. On peut d’abord documenter les colonnes, remplacer les permissions individuelles par des groupes, créer une vue des éléments bloqués, exporter les données et faire relire les règles par une deuxième personne.

Les permissions demandent un vrai test. Cacher une colonne dans le formulaire ou filtrer une vue ne protège pas sa valeur. Un utilisateur peut accéder à une autre vue ou à un export. Les données sensibles ont besoin de droits réels, d’une bibliothèque ou liste séparée si nécessaire et d’un journal des changements importants.

La reprise doit couvrir plus que la liste. Le workflow, ses formulaires personnalisés et ses dépendances doivent exister dans l’environnement restauré. On supprime un élément témoin, restaure la liste dans un site de test et vérifie qu’un responsable peut encore traiter une demande. Un export Excel est utile pour récupérer les valeurs; il ne recrée pas automatiquement les règles et permissions.

Les volumes révèlent enfin les limites. Une vue qui balaie des milliers d’éléments sans index devient lente. Les pièces jointes gonflent la base. Une alerte par modification produit une tempête de courriels. Il faut archiver les éléments fermés, indexer les filtres utiles et surveiller l’âge des demandes plutôt que le nombre total.

Comme chef d’équipe, je demanderais moins « qui a autorisé ça? » que « le travail continue-t-il quand l’auteur est absent? ». Si la réponse est non, l’outil a déjà franchi le seuil. On lui donne alors un propriétaire, une procédure de reprise et juste assez d’ingénierie pour soutenir la valeur qu’il produit réellement.