Provisionner à l’avance des appareils clients dans Meraki avec l’API

Le jour d’une installation réseau, le temps se perd rarement sur le branchement lui-même. Il se perd quand une imprimante apparaît sous un nom générique, qu’un écran de salle est confondu avec un autre ou que personne ne sait à quelle adresse MAC correspond le terminal posé au troisième étage.

Avec l’API Dashboard Cisco Meraki, une partie de ce travail peut être faite avant même que les équipements arrivent sur site. L’opération provisionNetworkClients permet de déclarer des appareils clients à partir de leur adresse MAC, de leur donner un nom d’affichage et de leur associer une politique. La documentation précise explicitement que ces clients peuvent être provisionnés avant leur première association au réseau.

Le résultat est simple : lorsque l’équipement se connecte, le Dashboard n’a pas à partir d’une identité inconnue. Le technicien, le support et l’exploitant disposent déjà d’un nom compréhensible et, si le projet le prévoit, d’une politique réseau préparée à l’avance.

Dans le vocabulaire du Dashboard, un client est un terminal qui utilise le réseau : ordinateur, téléphone, imprimante, écran, contrôleur d’accès, appareil audiovisuel, terminal de paiement ou objet connecté. Ce n’est pas la même chose qu’une borne MR, un switch MS ou un routeur MX administré par Meraki.

L’opération décrite ici ne sert donc pas à revendiquer une borne ou à ajouter son numéro de série dans l’inventaire Meraki. Elle sert à préparer les appareils qui se connecteront à un réseau existant. Cette distinction évite une confusion fréquente dans les projets où l’on installe simultanément l’infrastructure et les équipements métiers.

Le périmètre est celui d’un réseau Meraki identifié par son networkId. Deux sites appartenant à la même organisation possèdent généralement des identifiants de réseau différents. Une adresse MAC préparée sur le réseau du siège n’est pas automatiquement provisionnée sur celui d’une agence.

Sans préparation, Meraki découvre le client lors de son premier trafic. Le Dashboard peut alors afficher un nom DHCP, un nom mDNS, un constructeur déduit du préfixe MAC ou une simple adresse. Ces informations sont utiles, mais elles ne correspondent pas toujours au vocabulaire de l’entreprise.

Samsung, Apple ou HP n’indique pas si l’appareil est l’écran de la salle Atlas, le Mac de prêt du support ou l’imprimante d’étiquettes de la réception. Un nom préparé comme PARIS-3E-ATLAS-ECRAN-01 apporte immédiatement un contexte opérationnel.

Cette préparation présente plusieurs intérêts concrets.

Le technicien peut comparer le bordereau d’installation à une liste déjà présente dans Meraki. Il n’a plus à attendre qu’un équipement génère du trafic, puis à deviner lequel vient d’apparaître parmi plusieurs nouveaux clients.

Quand un utilisateur signale que « l’écran de la grande salle ne fonctionne plus », le support retrouve plus vite le bon client, sa dernière connexion, son point d’accès, son VLAN ou sa consommation réseau. Cette visibilité complète utilement les journaux d’événements Meraki et les informations conservées dans l’outil de gestion de parc.

Un appareil métier n’a pas toujours besoin du même accès qu’un poste utilisateur. Une politique de groupe peut, selon les fonctions disponibles sur le réseau, appliquer des règles de pare-feu, des limites de bande passante, du filtrage, une planification ou un VLAN. La documentation Meraki sur les politiques de groupe rappelle qu’une seule politique peut être active sur un client à un instant donné.

Pour dix écrans, vingt imprimantes ou un déploiement multi-sites, un fichier préparé par le chef de projet peut alimenter un script. Le nommage ne dépend plus de la personne présente sur place. La convention devient reproductible et contrôlable.

Le résultat retourné par l’API contient notamment l’adresse MAC, le clientId, le nom et la politique. En conservant cette réponse avec le dossier de changement, l’entreprise peut distinguer ce qui a été préparé, ce qui a réellement été installé et ce qui reste à contrôler.

L’API ne corrige pas une mauvaise fiche de préparation. Avant l’appel, il faut disposer d’une source fiable, idéalement produite par le fournisseur ou relevée sur les équipements.

Pour un appareil doté d’Ethernet et du Wi-Fi, il peut exister plusieurs adresses MAC. Il faut préparer celle de l’interface qui sera réellement utilisée, ou les deux si le processus doit couvrir les deux modes de connexion. Le nom doit alors rester explicite, par exemple avec un suffixe -ETH ou -WIFI.

L’appel utilise la méthode POST sur le chemin suivant :

/networks/{networkId}/clients/provision

Le corps contient deux éléments obligatoires :

Chaque client peut aussi recevoir un name. Pour une politique Group policy, le champ groupPolicyId devient nécessaire. L’API accepte également policiesBySecurityAppliance pour préciser le comportement côté MX et policiesBySsid pour définir une politique par SSID.

Les clés de policiesBySsid sont les numéros des SSID, de 0 à 14, et non leurs noms affichés. Il faut donc vérifier la correspondance dans le réseau ciblé avant d’automatiser. Copier mécaniquement le numéro 3 d’un site à l’autre peut appliquer une politique au mauvais Wi-Fi si les configurations ne sont pas alignées.

Imaginons trois appareils qui seront installés la semaine suivante : un écran, une tablette de contrôle et un codec audiovisuel. Ils doivent recevoir la même politique de groupe 101.

Le corps JSON peut ressembler à ceci :

{
  "clients": [
    {
      "mac": "00:11:22:33:44:55",
      "name": "PAR-3E-ATLAS-ECRAN-01"
    },
    {
      "mac": "00:11:22:33:44:66",
      "name": "PAR-3E-ATLAS-CONTROLE-01"
    },
    {
      "mac": "00:11:22:33:44:77",
      "name": "PAR-3E-ATLAS-CODEC-01"
    }
  ],
  "devicePolicy": "Group policy",
  "groupPolicyId": "101"
}

Une réponse réussie utilise le statut HTTP 201 et renvoie les clients provisionnés avec leur clientId. Ce dernier est utile pour les contrôles suivants, notamment avec l’opération getNetworkClientPolicy.

Si les appareils ne doivent pas recevoir la même politique, il faut les séparer en plusieurs requêtes. Le tableau clients permet de regrouper les identités ; devicePolicy et groupPolicyId restent communs à la requête.

La bibliothèque Python officielle peut lire la clé depuis la variable d’environnement MERAKI_DASHBOARD_API_KEY. La documentation d’authentification Meraki recommande de ne pas inscrire la clé directement dans le code source.

import meraki


NETWORK_ID = "L_123456789"
GROUP_POLICY_ID = "101"

clients = [
    {"mac": "00:11:22:33:44:55", "name": "PAR-3E-ATLAS-ECRAN-01"},
    {"mac": "00:11:22:33:44:66", "name": "PAR-3E-ATLAS-CONTROLE-01"},
    {"mac": "00:11:22:33:44:77", "name": "PAR-3E-ATLAS-CODEC-01"},
]

dashboard = meraki.DashboardAPI()

response = dashboard.networks.provisionNetworkClients(
    NETWORK_ID,
    clients,
    "Group policy",
    groupPolicyId=GROUP_POLICY_ID,
)

for client in response["clients"]:
    print(client["mac"], client["clientId"], client.get("name"))

Ce code est volontairement court. Un outil réellement utilisé en production doit ajouter des contrôles : format des adresses MAC, doublons, noms vides, réseau autorisé, politique attendue, journal du changement et gestion des erreurs.

Il est également préférable de commencer par un mode de prévisualisation. Le script affiche alors ce qu’il ferait sans appeler l’API. L’opérateur valide le réseau, le nombre de clients et la politique, puis déclenche explicitement l’écriture.

devicePolicy est obligatoire, même si l’objectif principal est seulement de préparer le nom. La valeur Normal conserve le comportement par défaut du réseau.

Il existe toutefois une nuance d’affichage. La documentation Dashboard consacrée à la préconfiguration des politiques pour les appareils clients indique qu’un client ajouté avec la politique Normal n’apparaît pas nécessairement dans la liste habituelle avant sa première connexion. Les clients dotés d’une politique spécifique peuvent être retrouvés avec le filtre des clients ayant une politique.

Il ne faut pas attribuer une politique plus permissive uniquement pour rendre l’entrée visible. L’allow-list, par exemple, peut exempter le client de plusieurs contrôles. Si Normal correspond au besoin, on conserve Normal, on archive la réponse de l’API et on vérifie le nom lors de la première connexion.

Le provisionnement repose sur une égalité : l’adresse préparée doit être celle que Meraki observera. Cette hypothèse est généralement solide pour une imprimante Ethernet ou un contrôleur audiovisuel fixe. Elle l’est moins pour un ordinateur ou un téléphone qui utilise une adresse Wi-Fi privée.

Apple explique que ses appareils peuvent employer une adresse Wi-Fi privée afin de limiter le suivi entre réseaux. Android et Windows disposent de mécanismes comparables. Selon la plateforme et la configuration, l’adresse présentée peut être stable pour un SSID, tourner dans le temps ou différer de l’adresse imprimée sur l’appareil.

Avant de provisionner un parc Wi-Fi utilisateur par MAC, il faut donc répondre à trois questions :

Le nommage par MAC est excellent pour l’exploitation d’équipements fixes. Il ne doit pas être confondu avec une preuve forte d’identité ou d’autorisation.

L’API propose plusieurs valeurs, mais elles n’ont pas toutes le même effet :

Le nom Allowed peut donner l’impression d’un simple feu vert. En pratique, la documentation Meraki sur le blocage et l’allow-list décrit des exemptions importantes, notamment vis-à-vis de règles de pare-feu et de certaines fonctions de sécurité selon le produit. Cette valeur ne devrait donc pas devenir le choix par défaut d’un script de préparation.

Pour un équipement métier, une politique de groupe minimale et explicitement documentée est souvent plus lisible : accès aux seuls services nécessaires, DNS et NTP prévus, flux vers les plateformes du fabricant, éventuelles limites de bande passante et absence d’accès latéral inutile. La politique doit être testée sur un client pilote avant d’être appliquée à tout un lot.

Rassembler les adresses MAC, les noms, les sites, les interfaces et les responsables. Refuser les lignes ambiguës plutôt que de les compléter au hasard. La source peut être un export fournisseur, un fichier de recette ou une base de gestion de parc.

Associer chaque site à son networkId et chaque politique à son groupPolicyId. Ces identifiants techniques doivent être relus depuis l’environnement ciblé, pas copiés depuis une documentation ancienne.

Produire un récapitulatif : réseau, nombre de clients, politique, doublons, adresses invalides et noms trop longs. Cette étape sert de dry-run et peut être jointe au ticket de changement.

Provisionner un ou deux appareils représentatifs, conserver la réponse 201 et vérifier l’entrée. Cette approche détecte une mauvaise politique ou un mauvais réseau avant de toucher tout le parc préparé.

Regrouper les clients qui partagent réellement la même politique. L’API accepte plusieurs clients par appel ; il est inutile d’envoyer une requête par équipement si tous appartiennent au même lot.

La documentation des limites d’appels Meraki indique un budget normal de dix requêtes par seconde et par organisation, partagé entre les applications. Un script doit traiter les réponses 429, respecter Retry-After et éviter les boucles de vérification trop fréquentes. La bibliothèque officielle gère déjà une partie des mécanismes de reprise.

Le contrôle final compare la préparation à l’observation réelle : adresse MAC vue, nom affiché, réseau, SSID ou port, VLAN, politique, heure de première connexion et propriétaire. Un écart doit ouvrir une correction, pas être masqué par un renommage opportuniste.

Préparer un client dans Meraki n’effectue pas les opérations suivantes :

L’API prépare une identité d’exploitation et une politique réseau. Le reste appartient toujours au processus d’installation, à la conception du réseau d’entreprise et à la recette métier.

Un script de provisionnement possède un droit de configuration. Il doit être traité comme un outil d’administration, même s’il ne fait « que nommer des appareils ».

Quelques règles simples évitent les mauvaises surprises :

Dans un environnement multi-sites, il est utile de maintenir une table validée site → networkId et usage → groupPolicyId. La personne qui prépare le fichier travaille alors avec des noms métiers ; le script résout les identifiants techniques et refuse une valeur inconnue.

Le véritable intérêt de cette API n’est pas de gagner quelques clics. Il est de déplacer le travail au bon moment. Le nommage, la politique et le contrôle peuvent être préparés quand le chef de projet possède encore le bordereau fournisseur, le plan des salles et le temps de vérifier les données — plutôt que pendant une installation où chaque minute compte.

Cette anticipation rend la mise en service plus lisible, accélère le support et crée une continuité entre le projet, le chantier et l’exploitation. Elle fonctionne particulièrement bien dans une démarche standardisée d’intégration Cisco Meraki : conventions de nommage, politiques testées, scripts contrôlés et recette après première connexion.

BoucheCousue accompagne les entreprises dans la préparation, l’automatisation et l’exploitation de leurs réseaux Meraki. Contactez-nous pour cadrer un déploiement ou fiabiliser un processus de provisionnement.