Microsoft SharePoint + Ziggu

Microsoft SharePoint et Ziggu se connectent via l'API REST publique de Ziggu. Les documents que vous désignez comme partageables sont écrits dans le bon projet dans Ziggu, sous la bonne catégorie, et le client est notifié. SharePoint reste l'espace de travail de votre équipe avec ses brouillons et ses versions internes, et le portail client ne montre au client que ce que vous avez décidé de partager.

L'essentiel

• Microsoft SharePoint se connecte à Ziggu via l'API REST publique de Ziggu. Vous pouvez construire vous-même, faire construire par votre partenaire, ou utiliser un modèle prêt à l'emploi sur Peliqan.
• Les documents sont rattachés à un projet et à une catégorie de documents dans Ziggu, en s'appuyant sur votre structure de dossiers ou vos métadonnées SharePoint.
• Les clients n'obtiennent jamais d'accès SharePoint. Ils voient les documents écrits dans leur projet, et rien autour.
• C'est une connexion planifiée, pas événementielle. Un fichier apparaît dans Ziggu au passage suivant, et vous en fixez la fréquence.

Pourquoi ne pas partager le dossier SharePoint

Parce que ce dossier n'est pas prêt pour un client, et ne le sera jamais. Il contient des brouillons, des versions périmées, des notes internes et les fichiers d'autres clients. Partager un sous-dossier, c'est entretenir des droits sur chaque nouveau dossier indéfiniment, et un héritage mal réglé devient une fuite.

Le contournement habituel consiste à envoyer le PDF final par e-mail, et il crée son propre problème : plus tard, personne ne peut dire quelle version le client a reçue. Écrire le document dans le projet du client dans Ziggu règle les deux. Il y a une version courante, le client est notifié, et vous voyez qui l'a ouverte. Voir Documents.

Quelles données circulent entre Microsoft SharePoint et Ziggu

La première colonne est le nom que votre équipe connaît dans l'application, la seconde est l'endpoint que votre développeur appelle.

‍

Comment connecter Microsoft SharePoint à Ziggu ?

Trois voies, la même API en dessous. Choisissez celle qui correspond à qui va la maintenir.

1. Construire vous-même. Demandez un jeton d'intégration à Ziggu, puis écrivez contre api.ziggu.app/public. Les jetons sont émis par organisation. Référence : documentation de l'API Ziggu.
2. Faire construire par votre partenaire d'intégration. Même API, même jeton, la maintenance chez quelqu'un d'autre.
3. Utiliser un modèle prêt à l'emploi sur Peliqan. Déployé et configuré plutôt qu'écrit, et adapté client par client.

Quelle que soit la voie, une décision vient d'abord et commande tout le reste : la règle qui dit quel fichier appartient à quel projet. Un dossier par projet est la version simple. Une colonne de métadonnées est la version flexible. Fixez-la, faites tourner une fois sur un seul dossier projet, et regardez ce que le client verrait avant d'élargir.

Où les équipes l'utilisent

Partager la version approuvée, pas le dossier d'où elle vient

Votre équipe continue de travailler comme elle travaille, avec brouillons et révisions dans SharePoint. Seul ce que votre règle marque comme partageable franchit la frontière, donc le client reçoit le plan approuvé et ne voit jamais les six versions précédentes.

Laisser le dossier de réception se constituer tout seul

Chaque document qui doit atteindre le client à la réception est déjà dans SharePoint. Plutôt que de composer un dossier à la main à la fin, chaque document atterrit dans le projet du client dès qu'il est définitif, et le dossier existe parce que le projet est terminé.

Donner à tout un portefeuille la même structure documentaire

Un schéma de dossiers dans SharePoint devient la même structure de catégories dans chaque projet dans Ziggu. Un client sur un projet et un client sur un autre trouvent leurs documents au même endroit, et c'est ce qui rend le portail assez prévisible pour qu'on cesse de poser la question. Voir comment les promoteurs immobiliers utilisent Ziggu.

Ce que Microsoft SharePoint et Ziggu ne font pas

• C'est une connexion planifiée, pas événementielle. Un fichier enregistré dans SharePoint apparaît dans Ziggu au passage suivant. Vous fixez le rythme.
• Il n'y a pas d'application Ziggu dans SharePoint. Quelqu'un construit ou déploie la connexion, que ce soit vous, votre partenaire ou un modèle sur Peliqan.
• Les projets sont rapprochés, pas créés. Un document dont le dossier ou les métadonnées ne désignent pas un projet Ziggu existant n'a nulle part où atterrir, donc la règle doit être juste avant de passer à l'échelle.
• Ce qu'une implémentation donnée déplace se convient à la mise en place. Traitez le tableau ci-dessus comme la forme de la connexion, pas comme un contrat figé.
• L'API de Ziggu est limitée à 60 requêtes par minute tous endpoints confondus, ce qui détermine le premier chargement d'une bibliothèque existante.

Questions sur l'intégration SharePoint

Nos clients ont-ils besoin d'un accès SharePoint ?

Non. C'est précisément l'idée. Les clients ne voient que les documents écrits dans leur propre projet Ziggu.

Comment un fichier atterrit-il dans le bon projet ?

Par la règle que vous fixez : un dossier par projet, ou une colonne de métadonnées SharePoint qui le désigne. La connexion en déduit un projet Ziggu existant.

En combien de temps un document apparaît-il dans Ziggu ?

Au passage planifié suivant. Vous fixez le rythme.

Le client est-il prévenu à l'arrivée d'un document ?

Oui, comme pour tout autre document dans Ziggu. Vous voyez aussi qui l'a ouvert.

Dans quel sens cela circule-t-il ?

Les documents vont de SharePoint vers Ziggu. Tout le reste est une décision prise au moment de la construction.

Nous utilisons autre chose pour les documents. Est-ce que ça marche ?

Oui. Nextcloud et Dynamics 365 couvrent le même terrain, chacun par sa propre voie.

Dernière vérification : 28 août 2026.