Build vs. Buy : développer l'intégration du matériel ou utiliser une API ?

La décision que personne n'explique bien

Quand un client demande à votre SaaS de lire ses terminaux biométriques, deux chemins s'offrent à vous. Build : votre équipe étudie le protocole du fabricant, écrit l'adaptateur, monte l'infrastructure et maintient tout en vie. Buy : vous consommez une API gérée comme API Connect qui a déjà résolu ce problème et expose les équipements comme des endpoints REST.

La conversation commence souvent mal parce qu'on compare les mauvaises choses : on compare le prix du développement à le prix de l'abonnement. La comparaison correcte, c'est le coût total de possession de la première année contre une ligne dans votre budget. Voyons pourquoi.

Ce que le Build implique vraiment

Développer l'intégration soi-même n'est pas un sprint de deux semaines. C'est un module permanent de votre produit avec ces composants :

• Ingénierie du protocole : les terminaux ne parlent pas HTTP. Implémenter le mode push/ADMS signifie gérer des sessions, des formats binaires de transfert de données et des variations par famille de firmware. Chaque nouveau modèle est un nouveau dialecte.
• Infrastructure publique : pour que les équipements se connectent à votre SaaS, il vous faut un serveur avec une adresse publique stable, du TLS, de la haute disponibilité et une supervision 24/7. Ce n'est pas la même infrastructure que l'API de votre business : c'est une infrastructure de dispositif.
• Stockage des événements : chaque pointage arrive par son compte ; il faut une ingestion tolérante aux pics, une déduplication (les terminaux renvoient à la reconnexion) et des requêtes efficaces par plage de dates.
• Maintenance permanente : les firmware changent les comportements, les fabricants corrigent des bugs, les clients signalent des modèles rares. L'adaptateur n'est jamais « terminé » : il se maintient à vie.
• Sécurité : authentifier des dispositifs qui n'ont ni utilisateur ni mot de passe, avec tout ce que cela implique en risque et en audit.

Ce que le Buy implique vraiment

Avec une API gérée, le travail de l'adaptateur, l'infrastructure de connexion et la maintenance du protocole sont déjà faits et se maintiennent seuls. Votre part du travail, c'est celle qui apporte vraiment de la valeur à votre SaaS :

• Authentification : un login standard contre l'API vous donne un token JWT avec expiration.
• Consommation : rapports par terminal avec plage de dates et pagination, et événements en temps réel (par webhook ou flux) pour la logique urgente.
• Gestion : créations d'utilisateurs et d'identifiants par numéro de série via API.

curl -X POST https://TU-DOMINIO-API/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username": "tu_usuario", "password": "tu_password"}'

# Token prêt pour appeler l'API
{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...",
  "token_type": "bearer",
  "expires_in": 3600
}

La comparaison honnête

Quand le Build a VRAIMENT du sens

Pour ne pas être trompeurs : il existe des cas où construire est la bonne décision. Tous partagent ces caractéristiques :

• Vous avez une exigence très spécifique qu'aucune API n'expose (par exemple, le contrôle direct d'un périphérique non supporté).
• Vous avez une équipe d'ingénierie dédiée capable d'assurer la maintenance indéfinie sans sacrifier la roadmap.
• Votre roadmap produit inclut du matériel propre : l'adaptateur serait un actif stratégique, pas un rustine.
• Le volume justifie l'investissement : des milliers de terminaux où chaque centime par terminal change l'économie.

Si votre cas est « mon SaaS doit lire les terminaux ZKTeco de mes clients », aucun de ces quatre points ne s'applique. Vous êtes sur le territoire du Buy.

La règle de décision en une phrase

Construisez ce qui différencie votre produit ; achetez tout le reste. Votre SaaS ne rivalise pas sur le parsing du protocole ADMS — il rivalise sur une paie meilleure, des copropriétés mieux gérées, une sécurité meilleure. L'intégration de matériel est un moyen, pas votre produit.

Questions fréquentes