SharePoint
SP MicroApps : un moteur, plusieurs interfaces SharePoint
Quand des données vivent déjà dans SharePoint, un moteur SPFx peut créer des interfaces ciblées sans recréer le même socle pour chaque besoin.
Sur le terrain, le besoin revient souvent sous une forme très simple : les données sont déjà dans des listes et des bibliothèques SharePoint, mais les personnes veulent les consulter, ajouter une information ou la modifier dans une interface plus agréable.
Une liste de projets peut contenir les bonnes colonnes et rester difficile à parcourir. Une liste de demandes peut être complète, mais ne pas faire ressortir ce qui attend une décision.
Une bibliothèque documentaire peut contenir les bons fichiers, sans offrir un parcours clair autour de leurs métadonnées.
Il ne faut pas répondre automatiquement par une nouvelle application. SharePoint propose déjà des vues, des formulaires et de la mise en forme. La documentation Microsoft montre notamment comment adapter les vues de listes et bibliothèques. Power Apps est aussi une option solide pour créer ou personnaliser un formulaire connecté à une liste SharePoint. Microsoft en décrit l’intégration.
Le POC SP MicroApps examine un troisième cas : plusieurs expériences proches doivent rester dans SharePoint et partager une partie de leur fonctionnement. L’idée n’est pas de remplacer les capacités natives ni Power Apps. Elle consiste à développer une petite famille d’interfaces lorsque cette mutualisation apporte une valeur réelle.
| Situation | Première option à examiner |
|---|---|
| Les vues et formulaires existants répondent au besoin | Rester dans les capacités natives de SharePoint |
| Un processus ou un formulaire low-code convient à l’équipe | Examiner Power Apps |
| Plusieurs interfaces SharePoint proches doivent partager des comportements | Examiner un moteur SPFx comme ce POC |
Cette dernière option a une contrepartie honnête : le moteur est du logiciel. Il faut le développer, le déployer, le tester et le maintenir. Il ne fait pas disparaître ce travail ; il évite de le répéter pour chaque interface compatible.
Un socle commun pour trois démonstrations
SP MicroApps rassemble un Web Part générique, une configuration contrôlée, un accès partagé aux données et des templates inclus dans un même package. Le moteur gère les parties communes : chargement, erreurs, validation de la configuration, accès aux données et gestion des conflits. Project Hub et Request Hub réutilisent aussi certains composants de formulaire. Chaque template se concentre ensuite sur une présentation adaptée à une source compatible.
Les trois démonstrations du POC ont reçu les noms Project Hub, Request Hub et Document Hub. Elles ont été développées pour éprouver ce même moteur sur des présentations et des sources différentes.
Project Hub : rendre un portefeuille lisible
La source est une liste de projets avec, par exemple, un titre, un statut et une progression. Project Hub transforme ces valeurs en cartes, indicateurs, recherche et filtres. Une modification faite dans le parcours d’édition revient dans cette même liste SharePoint.
LOCAL MOCK PREVIEW — données synthétiques. La capture montre le rendu Project Hub. L’accès aux listes, la validation de configuration et les états de chargement restent ceux du moteur commun.
Request Hub : un autre travail, les mêmes fondations
Request Hub utilise une source compatible avec les demandes : type, demandeur, statut et autres champs attendus par ce template. À l’écran, le résultat est volontairement différent : listes opérationnelles, résumés de statut, filtres et parcours de création ou de modification. En dessous, le Web Part, l’accès SharePoint et les protections de configuration sont partagés.
LOCAL MOCK PREVIEW — données synthétiques. Cette capture illustre le rendu Request Hub, pas une application séparée.
Document Hub : les mêmes principes pour les fichiers
Document Hub applique l’approche aux bibliothèques documentaires : trouver un fichier, lire ou modifier des métadonnées mappées, puis, si cette capacité est activée, déposer un fichier. Il gère notamment des champs Person et Lookup à valeur unique. Le template reste une entrée ciblée vers SharePoint, pas un système complet de gestion documentaire.
LOCAL MOCK PREVIEW — données synthétiques. La capture sert à comprendre le parcours d’upload ; elle ne prouve pas une intégration SharePoint réelle.
Du contenu de liste à l’interface : un exemple concret
Le point de départ est une liste dont les colonnes correspondent à ce que le template sait afficher. La configuration ne transforme donc pas arbitrairement n’importe quelle liste en n’importe quelle expérience. Elle associe une source compatible et ses noms internes de champs aux attentes du template.
Le manifest est une configuration applicative JSON stockée dans la liste SP MicroApps du site courant. Son App ID est une clé logique : le Web Part l’utilise pour retrouver la bonne configuration. Ce n’est ni un manifest SPFx, ni un identifiant Entra. Voici un extrait réel, raccourci et volontairement incomplet du manifest Project Hub du POC ; il explique le principe, mais ne peut pas être copié tel quel :
{
"id": "project-hub-main",
"template": "project-hub",
"dataSources": {
"projects": { "type": "sharepoint-list", "listTitle": "Projects" }
},
"mapping": { "title": "Title", "status": "Status", "progress": "Progress" }
}
Dans cet exemple, template choisit le rendu Project Hub. dataSources désigne la liste à lire dans le site courant. mapping relie les valeurs métier de cette liste aux champs que le template attend. React peut alors composer une carte avec le titre, le statut et la progression. Lorsqu’une personne modifie une valeur autorisée, le provider l’enregistre dans la même source SharePoint et l’interface relit le résultat.
Une autre configuration peut sélectionner Request Hub, sa liste de demandes compatible et ses propres mappings. Elle ne télécharge pas un nouveau template depuis la liste : le template est déjà dans le package. La validation est fermée aux options prévues ; une configuration invalide, désactivée ou incohérente s’arrête avant la lecture des données métier.
Sous le capot, sans magie
Le Web Part SPFx héberge l’application dans SharePoint. React s’exécute dans le navigateur pour composer les cartes, les listes et les formulaires ; ce POC n’ajoute pas de backend séparé. Derrière cette interface, une couche d’accès aux données — IDataProvider dans le POC — isole la manière dont les templates demandent leurs données. Son implémentation SharePoint s’appuie sur SPHttpClient et SharePoint REST.
Au chargement, le moteur retrouve la configuration grâce à l’App ID, la valide, puis lit la source compatible. React sélectionne le template inclus et affiche les données. Lorsqu’une personne enregistre un formulaire, le template passe par le provider pour appeler SharePoint REST. Si SharePoint accepte la modification, les données sont relues pour actualiser l’affichage ; sinon, l’interface signale l’erreur.
À observer dans le schéma : configuration validée, moteur, template inclus, puis données SharePoint du site courant. La réutilisation suppose toujours une source et des champs compatibles.
Cela ne crée pas une autorisation parallèle. Le moteur peut consulter les capacités effectives pour adapter les actions proposées ; SharePoint autorise ou refuse les lectures et les écritures sous l’identité de la personne connectée. Les permissions de liste, d’élément et de bibliothèque restent donc l’autorité.
Le package contient les templates exécutables déjà construits. Une configuration peut choisir une capacité existante, connecter une source, définir ses bindings, ses libellés ou certaines options disponibles. Une nouvelle interaction, un nouveau template ou une nouvelle capacité demande du développement puis une mise à jour du package. C’est la frontière pratique entre configuration et code.
Stack du POC. Le projet est écrit en TypeScript, avec SPFx 1.23.2 et React 17.0.1. Node.js 22 et Heft servent à compiler le code en JavaScript et à produire le package
.sppkg. Le navigateur exécute ensuite le JavaScript livré ; Node.js et Heft interviennent uniquement pendant la construction.
La démonstration historique Project/Request, avec le package 1.0.0.3, a vérifié ce point : la même page et le même App ID sont passés d’un template à l’autre par changement de manifest. Les assets JavaScript déployés sont restés identiques ; le moteur a sélectionné un autre template déjà inclus. Il n’y a eu ni build, ni déploiement, ni remplacement d’asset pendant cette bascule.
Construire avec des agents IA
Le POC a été développé avec l’assistance d’agents IA, à partir d’un cadrage précis : contrat de configuration fermé, capacités incluses dans le package et frontière nette entre ce qu’un site peut configurer et ce qui demande du code. Les agents interviennent pendant le développement ; l’application livrée fonctionne avec SPFx, React et SharePoint REST.
Le travail a été réparti en tâches bornées : provider, interfaces, contrats, tests et relecture. Cette répartition rendait possible une vérification croisée des modifications avec les contrats concernés et avec le comportement observé dans SharePoint.
Un essai de dépôt en doublon l’illustre. SharePoint a renvoyé une réponse que le prototype classait comme une erreur inconnue. Le traitement a été corrigé pour reconnaître le conflit et laisser l’utilisateur renommer le fichier, sans perdre sa sélection ni les informations saisies. Ce cas a ensuite été couvert par des tests ciblés et contrôlé sur une vraie bibliothèque.
Pour réutiliser cette méthode, le point de départ est un contrat et un critère de vérification pour chaque tâche confiée à un agent. Le code proposé peut alors être confronté aux autres composants, aux tests et au comportement réel de la plateforme.
Périmètre et preuves du POC
Les limites Document Hub sont celles de ce POC, non celles de SharePoint : une à huit bibliothèques du même site, jusqu’à 500 documents dans l’ensemble de travail, et un fichier de 20 MiB maximum déposé à la racine d’une bibliothèque du site. Les notifications, approbations, rétention, upload en lot, transfert par morceaux et gestion des records ne sont pas inclus.
L’extension documentaire a été vérifiée ensuite avec le package 1.3.0.1 : trois fichiers de démonstration ont été déposés dans SharePoint, puis leurs métadonnées ont été relues. Pour cet incrément documentaire, la limite de taille, les refus de permission, les conflits ETag et les réponses ambiguës ont été contrôlés par simulation. Ces vérifications ne rejouent pas tous les scénarios historiques de Project Hub et Request Hub sur cette version.
Les captures de cet article sont des illustrations locales avec données synthétiques ; elles ne constituent pas la preuve de ces essais SharePoint.
Ce que cette approche permet de retenir
Le principe réutilisable est simple : développer une famille limitée d’interfaces, mutualiser leur fonctionnement, puis configurer leurs usages tant que le besoin reste dans ce périmètre. Dès que le besoin sort de cette famille, il faut choisir une autre option ou développer une nouvelle capacité.