Disponibilité : les capacités API/Webhooks peuvent dépendre de votre édition et de votre contrat. Rapprochez‑vous de votre interlocuteur Hamilton Apps pour l’activation et la portée exacte.
1) Cas d’usage fréquents
Affichage temps réel : mur d’écrans, intranet d’équipe, « prochaines réunions ».
Automatisation IT/Workplace : création de tickets (logistique/IT) à la réservation ou à la modification.
Pilotage équipements : préparer la visioconf/domotique selon la salle et l’horaire.
BI & reporting : synchroniser les réservations, no‑shows et libérations vers un data‑lake.
Conformité : centraliser les journaux d’activité (SIEM), supervision.
2) Concepts — API vs Webhooks
API (pull) : votre SI interroge Meeting pour lire (et selon droits, écrire/mettre à jour) des ressources (réservations, salles…).
Webhooks (push) : Meeting appelle vos endpoints HTTPS lorsqu’un événement survient (ex. reservation.created, reservation.updated, reservation.cancelled, checkin.performed, room.released, service.added).
Sécurité (principes)
Authentification par token (Bearer) pour l’API ; signature (ex. HMAC) des webhooks avec secret partagé.
Moindre privilège : tokens scopés au périmètre utile (lecture/écriture).
Réseau : endpoints webhook HTTPS uniquement, idéalement avec allow‑list d’IP côté pare‑feu.
3) Mise en œuvre — API (généralités)
Générer un token d’accès dans Administration → Intégrations → API (scopes lecture/écriture selon besoin).
Tester un appel de lecture (ex. liste des réservations d’un site/période) en filtrant par dates/salles.
Pagination & limites : prévoir la pagination (page/limit) et respecter les éventuels rate‑limits (réessais exponentiels).
Idempotence : pour l’écriture/annulation, inclure un identifiant de requête unique pour éviter les doublons en cas de réessai.
Fuseaux & formats : travailler en UTC (ISO 8601) et afficher côté SI en fuseau local.
Schéma d’appel (illustratif)
GET /api/meetings?site=HQ&start=2025-11-01T00:00:00Z&end=2025-11-07T23:59:59Z Authorization: Bearer <TOKEN>
Réponse (extrait minimal)
{ "data": [ {"id":"res_123","room_id":"room_PAR_A02","title":"Sprint Review", "start":"2025-11-05T09:00:00Z","end":"2025-11-05T10:00:00Z", "organizer":"[email protected]","participants":["[email protected]"], "status":"confirmed"} ], "page":1, "has_more":false }4) Mise en œuvre — Webhooks (généralités)
Déclarer un endpoint HTTPS dans Administration → Intégrations → Webhooks (URL + secret).
Choisir les événements à recevoir (ex. reservation.created/updated/cancelled, checkin.performed, room.released, panel.event, service.added/updated/cancelled).
Vérifier la signature : Meeting envoie une signature basée sur le corps et le secret ; votre SI recalcule et compare.
Accuser réception par un code 2xx. En cas d’erreur (≠2xx), Meeting réessaie (back‑off).
Idempotence : utilisez l’
event_idpour ignorer les doublons.
Payload type (illustratif)
{ "event_id": "evt_7f9a", "event_type": "reservation.updated", "occurred_at": "2025-11-05T08:15:00Z", "tenant_id": "tn_abc", "data": { "id": "res_123", "room_id": "room_PAR_A02", "changes": {"start":"2025-11-05T09:30:00Z","end":"2025-11-05T10:30:00Z"} } }5) Bonnes pratiques d’intégration
Testez sur un périmètre pilote (site/salles de test) avant généralisation.
Journalisez côté SI (requêtes, réponses, échecs, IDs d’événements).
Relecture : exposez une API /replay interne pour rejouer les events en échec après correction.
Cohérence Outlook : effectuez les modifications côté Meeting (pas directement dans Outlook) pour éviter les écarts.
Données minimisées : ne stockez que les champs nécessaires (RGPD), chiffrez au repos dans vos systèmes.
6) Exemples d’usages (recettes)
Tableau d’affichage : consommer l’API planning toutes les 60 s, cache mémoire 2–5 min, affichage maintenant + prochain créneau par salle.
Ticket logistique : webhook reservation.created → créer un ticket avec salle/date/participants ; webhook cancelled → fermer/annuler le ticket.
KPIs occupation : webhook checkin.performed & room.released → alimenter un compteur effectif ; consolidation horaire dans votre BI.
7) Sécurité & conformité
Rotation régulière des tokens/secrets ; stockés en coffre‑fort.
Allow‑list des IP sortantes d’Hamilton (si fournie) sur vos endpoints.
TLS à jour, interdiction des ciphers faibles.
Droits : restreindre les scopes des tokens (lecture seule si suffisant).
RGPD : minimiser, définir des durées de conservation, et documenter les finalités.
8) Dépannage rapide
401/403 (API) : token expiré/mauvais scope → regénérer ; vérifier l’horloge système.
Signatures invalides (webhook) : clé/secret non synchronisé ou corps altéré → recalculer, vérifier l’horodatage.
Boucles / doublons : utiliser
event_idet idempotency‑key côté SI.Retards d’affichage : réduire le polling ou passer par webhooks + cache.
Écarts Outlook : appliquer les modifications depuis Meeting pour forcer la propagation.
Surcharge : respecter les rate‑limits et back‑off exponentiel.
Pré‑requis
Rôle : Administrateur Meeting.
Endpoint HTTPS exposé pour les webhooks (public ou via passerelle).
Processus IT pour la gestion des secrets et la supervision (journaux/alertes).
Liens associés
Côté Admin
Synchronisation calendriers (Microsoft Graph / Exchange)
Politiques de réservation
Panneaux de salles & capteurs de présence
Rapports d’usage & taux d’occupation
Outils d’exploitation
Journal d’activité & audit
Côté DSI/RSSI
Conformité & sécurité
Maintenance & support (SaaS)