Customer HubCalendrier (CalDAV)
La configuration Calendrier transmet un compte CalDAV à l’application Calendrier native d’iOS et d’iPadOS via un profil de configuration, ce qui évite toute configuration manuelle par l’utilisateur final. Sur les versions récentes d’iOS, les chemins de calendrier associés au compte sont déterminés automatiquement selon la RFC 6764, via une redirection sous /.well-known/caldav. Une redirection /.well-known/caldav correctement configurée côté serveur est donc obligatoire sur les versions récentes d’iOS ; la seule indication d’une URL principale (Principal URL) n’y suffit plus.
La configuration est également disponible pour les appareils en inscription des utilisateurs →.
Options de configuration
Les champs suivants sont disponibles pour le compte CalDAV. Ils correspondent aux clés de la charge utile CalDAV d’Apple (com.apple.caldav.account).
Paramètres du compte
- Description du compte — nom affiché du compte sur l’appareil.
- Nom d’hôte (obligatoire) — adresse du serveur sous forme de nom DNS, sans schéma, port ni chemin (par exemple
calendrier.example.com). Les adresses IP seules ne sont pas acceptées. - Port — en règle générale
443. Le champ n’est pas prérempli. - Utilisez le protocole SSL — activé par défaut ; à laisser activé lorsque le serveur est accessible via HTTPS. Sans SSL actif, une connexion non chiffrée est tentée sur le port
443, ce qui échoue. - Nom d’utilisateur (obligatoire) — saisi manuellement ou via des espaces réservés tels que
${user.name}ou${user.email}. D’autres espaces réservés sont répertoriés dans la section Espaces réservés disponibles sous le formulaire. - Mot de passe — s’il n’est pas renseigné, il est demandé sur l’appareil lors de l’installation du profil.
- URL principale (facultatif) — l’URL complète du principal de l’utilisateur, avec schéma et hôte (par exemple
https://calendrier.example.com/remote.php/dav/principals/users/${user.name}/).
https://calendrier.example.com/...). Un chemin simple tel que /remote.php/dav/... est signalé comme non valide (« doit être une URL valide ») et la configuration ne peut pas être enregistrée. L’hôte et le schéma de l’URL doivent correspondre aux champs Nom d’hôte et Utilisez le protocole SSL. Sur les versions récentes d’iOS, une URL principale renseignée ne remplace toutefois plus la détection automatique — c’est une redirection /.well-known/caldav correctement configurée qui est déterminante. Le champ peut donc rester vide.VPN par compte
Le compte CalDAV peut être référencé dans une configuration VPN, dans la section VPN par compte, afin que la connexion au serveur de calendrier passe par ce VPN. Le formulaire de la configuration Calendrier affiche alors la mention « Cette configuration est référencée par une configuration VPN. » avec le lien Afficher la configuration référencée. La mise en place du VPN est décrite dans Mappage App vers VPN →.
Détection automatique via .well-known
Les versions récentes d’iOS configurent les comptes CalDAV selon la RFC 6764. Le déroulement est le suivant :
- Requête
PROPFIND /.well-known/caldavvers le serveur indiqué sous Nom d’hôte. - Le serveur répond par une redirection (
301) vers son point de terminaison DAV (/remote.php/davpour ownCloud/Nextcloud). - Le point de terminaison DAV permet de déterminer le
current-user-principalet, à partir de là, l’espace calendrier de l’utilisateur.
La fiabilité de la configuration dépend donc entièrement d’une redirection /.well-known correcte. Sur les versions récentes d’iOS, la détection automatique ne peut plus être contournée par l’indication d’une URL principale — sans redirection /.well-known fonctionnelle, la configuration échoue, même si une URL principale est renseignée.
http:// au lieu de https://), encore tolérée sous iOS 17, provoque l’interruption de la détection sur les versions actuelles. Les comptes déjà configurés sous iOS 17 sur d’anciens appareils peuvent continuer de fonctionner alors que les nouvelles configurations échouent.Configuration de la redirection côté serveur
/.well-known/caldav et /.well-known/carddav doivent rediriger par 301 vers le point de terminaison DAV du serveur. L’adresse cible doit impérativement commencer par https:// et ne doit pas contenir de port interne.
Pour nginx :
location = /.well-known/caldav { return 301 https://$host/remote.php/dav; }
location = /.well-known/carddav { return 301 https://$host/remote.php/dav; }
Pour Apache (dans le vHost) :
Redirect 301 /.well-known/caldav https://calendrier.example.com/remote.php/dav
Redirect 301 /.well-known/carddav https://calendrier.example.com/remote.php/dav
8080), le serveur web ne connaît souvent son adresse publique que comme http sur le port interne. La redirection générée est alors erronée, par exemple http://calendrier.example.com:8080/remote.php/dav. Les versions récentes d’iOS ne suivant pas un passage de https à http, la détection échoue. Dans ce cas, la redirection doit être définie avec une adresse cible https:// complète — soit directement sur le proxy qui termine le TLS, soit comme URL cible absolue, comme dans l’exemple Apache.Vérification
La redirection peut être vérifiée avec curl :
curl -sI https://calendrier.example.com/.well-known/caldav
La réponse doit contenir une redirection avec un en-tête location correct :
HTTP/2 301
location: https://calendrier.example.com/remote.php/dav
L’en-tête location doit commencer par https:// et ne doit pas contenir de port interne (par exemple :8080).
Résolution des problèmes
| Symptôme | Cause | Solution |
|---|---|---|
| La configuration échoue uniquement sur les versions récentes d’iOS ; les anciens appareils continuent de fonctionner | La redirection pointe vers http:// (rétrogradation) ; les anciennes versions d’iOS le toléraient | Corriger la redirection vers https:// |
Le 301 pointe vers un port interne (par exemple :8080) | Reverse proxy/terminaison TLS, le serveur web ne connaît pas son adresse publique | Définir la redirection avec l’adresse https:// complète sur le proxy ou le serveur web |
405 Method Not Allowed sur des chemins tels que / ou /principals/ | La détection automatique n’aboutit pas et teste des chemins par défaut qui n’existent pas sur le serveur | Configurer correctement la redirection /.well-known (obligatoire sur les versions récentes d’iOS) |
| Le chemin déterminé est manifestement incorrect | URL principale renseignée avec un hôte différent ou avec http:// au lieu de https://, ou Utilisez le protocole SSL non activé | Indiquer l’URL principale avec https:// et le serveur saisi sous Nom d’hôte, ou laisser le champ vide, et activer Utilisez le protocole SSL |
Délimitation du problème sur l’appareil
Pour délimiter le problème, un compte CalDAV peut être configuré à titre de test directement sur l’appareil sous Réglages → Calendrier → Comptes. Si le compte configuré manuellement se connecte alors que le compte distribué par profil échoue, la cause se situe dans la détection automatique (/.well-known) ou dans l’URL principale distribuée via le profil — et non dans le serveur lui-même.
Utilisation sous macOS
La configuration CalDAV et le prérequis /.well-known côté serveur s’appliquent de manière identique à macOS :