Un seul port ouvert, cinquante sites et toutes les limites écrites

La première question d’un service réseau n’est jamais ce que détecte la caméra : c’est quels ports il faut ouvrir. IRIS écoute sur quatorze, mais un seul traverse le pare-feu, le 443. Les treize autres n’écoutent qu’à l’intérieur de la machine, et ce n’est pas enfoui dans le programme : c’est une politique visible et modifiable depuis le web. Pour le client, cela fait treize exceptions à ne pas demander, ni documenter, ni justifier devant un auditeur, ni revoir chaque année, et treize portes que personne ne laissera ouvertes des années après la disparition du composant qui les réclamait. Sur une installation répartie, cela fait aussi treize négociations en moins avec chaque antenne, qui a souvent ses propres règles ; quiconque s’est déjà battu avec un service réseau sait exactement ce que cela vaut. Et quand quelque chose cloche, tout le contrôle réseau se résume à une question : le 443 passe-t-il.

Une seule installation pilote des serveurs répartis entre sites, pays et fuseaux horaires, et on les manie comme s’ils n’en faisaient qu’un. Les organisations s’imbriquent sans limite de profondeur — groupe, pays, région, client, site — et les droits se délèguent en conséquence : le responsable d’un site touche le sien, le centre voit tout. Chaque organisation, chaque serveur et chaque caméra portent leur propre fuseau, si bien que comparer l’heure de pointe de quatre pays ne fausse aucune série. Et surtout : ce n’est pas un cerveau central dont dépendrait la surveillance. Chaque site capte ses caméras, détecte, applique ses règles, enregistre et commande ses relais en local, et seuls des événements et des mesures remontent au centre, jamais des images. Si la liaison tombe, le site continue de travailler et publie son arriéré dès qu’elle revient.

Le produit annonce plus de cent mille serveurs et plus de cinq millions de caméras, mais ce chiffre seul ne prouve rien : n’importe qui peut l’écrire. Ce qui le tient, c’est que les huit limites du produit sont publiées, chacune avec son unité de répartition, et que trois se règlent en ajoutant des machines tandis que cinq sont un mur qu’il faut respecter. Un exemple parmi celles qui se répartissent : soixante-quatre caméras tiennent par processus de capture, donc cinq mille caméras font soixante-dix-neuf processus répartis sur autant de machines qu’il faut. C’est une réponse d’ingénieur, et publier ses propres murs est la meilleure preuve de confiance dans un produit qui soit : scalable, n’importe qui l’écrit ; ses huit limites, presque personne. Et le calcul ne se fait pas sur un tableur commercial : il y a une calculatrice dans le produit qui pose douze questions, dit quels équipements il faut, signale quelle ressource s’épuise en premier et déclare irréalisable — pas risqué — un dimensionnement qui franchit une limite non répartissable. Chaque chiffre rendu porte son origine écrite, et elle indique noir sur blanc ce qui n’a pas encore été mesuré dans cette installation-là.

Ce que le système mesure, on peut le sortir. On lui demande son catalogue de données et il rend tout ce qu’il sait calculer et tout ce par quoi on peut regrouper, noms déjà traduits : c’est le vocabulaire des écrans, il n’y a donc pas d’interface de seconde zone pour ceux du dehors. Les limites sont annoncées d’emblée, ce qu’apprécie quiconque développe contre elle : la plage de dates est obligatoire, une réponse porte au plus cinquante mille lignes, et une requête trop large est refusée avec son motif écrit plutôt que de se dégrader en silence. Vers l’extérieur, le système parle à des caméras de n’importe quel fabricant par protocoles standard, commande des relais de barrière, de tourniquet ou de sirène, alerte par courriel et messagerie, appelle des systèmes externes et exporte vers un tableur. Et tout cela se fait avec la même identité d’utilisateur et par le même port : il n’y a pas d’annuaire d’utilisateurs séparé pour les intégrations.

Les huit limites, une par une, parce que c’est exactement ce qu’un intégrateur demandera en démonstration. Trois se répartissent : 64 caméras par processus de capture, 8 192 connexions vives au point d’entrée et les 1 000 qu’une seule instance sert à la fois ; les trois se règlent en ajoutant des processus ou des points d’entrée. Les cinq autres sont un mur : 64 consommateurs par caméra —chaque enregistreur, chaque détecteur et chaque visionneuse en prend un—, 16 384 ports temporaires du système d’exploitation, qui n’est même pas une limite de chez nous et explique la précédente, 8 images par lot du moteur de détection, 600 images retenues par consommateur, le multiplicateur qui fait exploser la mémoire dès que la résolution monte, et une carte graphique par processus, car un modèle ne se coupe pas en deux : soit il tient entier, soit il faut deux copies. Ces cinq-là ne se règlent pas en achetant des machines, et c’est précisément pour cela qu’ils sont écrits au lieu d’être cachés. Avec cette liste et la calculatrice, un intégrateur peut dimensionner une installation sans nous appeler.

L’analytique n’est pas un module à part qui copie les données : c’est la même source que les écrans, agrégée. Sept mesures, seize dimensions pour regrouper et filtrer, vingt-sept types de visualisation et cinq formats d’export générés dans le navigateur lui-même, hors connexion. Et voici le détail qui trahit celui qui l’a vraiment fait : les mesures qu’on ne peut pas réagréger sans mentir —les objets distincts, le temps de présence et l’occupation moyenne pondérée par le temps— sont marquées comme telles et servies depuis le détail, parce qu’une somme de sommes ne veut rien dire. L’interface de programmation rend la même chose sous les mêmes règles : la plage de dates est obligatoire, la pagination ne se dégrade pas en avançant, et une erreur de droits, une de vocabulaire et une de plage ne se confondent jamais. Et le périmètre de ce qu’on peut voir se résout sur le serveur à partir des droits de celui qui demande : une requête peut rétrécir ce qu’elle voit, jamais l’élargir.