Pointage biométrique sans IP fixe : résoudre le problème de réseau une fois pour toutes

Le blocage le plus courant du secteur

Un client veut du pointage biométrique dans 5 franchises. Trois utilisent internet résidentiel, une le 4G et la cinquième est sur chantier. Le fournisseur local répond : « il nous faut une IP fixe sur chaque site ». Et là, le projet meurt : l'IP fixe coûte plus cher, n'est parfois même pas disponible, et configurer 5 réseaux différents n'est pas un plan — c'est une liste de tickets.

Le problème de fond, c'est le modèle de connexion : si votre logiciel entre dans le réseau du client pour lire la pointeuse, le réseau du client doit être accessible de l'extérieur. C'est cette exigence qui crée tout le problème.

Les options traditionnelles (et leur coût réel)

Comment fonctionne le mode push (version conceptuelle)

Les terminaux ZKTeco modernes prennent en charge un mode où c'est l'appareil qui sort : il se connecte à l'adresse du serveur dans le cloud et lui livre ses événements — pointages, impulsions de vie, synchronisations — de sa propre initiative, sans que personne n'entre dans le réseau où il est installé.

Les conséquences pratiques :

• L'IP du client peut être dynamique et changer quand elle veut : peu importe, car vous n'entrez jamais dans son réseau.
• La 4G fonctionne : un routeur avec SIM est l'installation la plus courante sur chantier et lors d'événements.
• Plusieurs sites derrière un seul NAT : plusieurs terminaux partagent la même sortie internet sans conflit.
• Zéro ticket réseau : pas de ports à ouvrir, ni de règles de pare-feu à négocier avec le client.

Ce que cela signifie pour votre logiciel

Si vous développez le système (ERP, paie, gestion de copropriétés), le mode push change la conversation d'implémentation :

• Onboarding en heures, pas en semaines : le technicien du site configure simplement l'adresse du serveur dans le terminal et le numéro de série reste enregistré dans votre plateforme.
• Multi-sites sans infrastructure : chaque succursale est un terminal de plus dans l'API, pas un projet réseau.
• Événements en temps réel : vous recevez chaque pointage à l'instant, vous n'importez pas des fichiers en fin de journée.

Consommer les événements depuis votre backend ressemble à ceci :

import { createClient } from 'redis';

const sub = createClient({
  socket: { host: process.env.REDIS_HOST, port: Number(process.env.REDIS_PORT) },
  password: process.env.REDIS_PASSWORD
});

await sub.connect();

await sub.subscribe('punch_VOTRE-SERIAL', (message) => {
  const event = JSON.parse(message);
  // marquer la présence dans votre système, notifier, déclencher des règles...
  console.log(event.pin, event.timestamp);
});

Et si vous préférez consulter plutôt qu'écouter, l'API REST expose les rapports par terminal avec plage de dates et pagination.

Et si internet tombe sur le site ?

C'est la bonne question. Les terminaux stockent les pointages dans leur mémoire locale tant qu'il n'y a pas de connexion et les renvoient quand le réseau revient : l'appareil est tolérant aux coupures temporaires. Pour votre logiciel, la recommandation est simple : utilisez les événements en temps réel pour l'urgent (notifications, accès) et le rapport REST comme source de vérité pour la réconciliation.

Questions fréquentes