Notes de décembre 2024, mises au propre pour ce blog — contexte et détails anonymisés.
La demande arrive un mardi matin. On veut les images de la semaine passée, entre 22h et 23h. J'ouvre le VMS, je pose la fenêtre horaire, je sors la séquence. Et l'heure ne colle pas : l'enregistreur retarde de onze minutes sur le reste du parc. Depuis quand, à quelle vitesse ? Personne ne sait. À partir de là, tout ce qu'on va sortir est discutable.
Autant le dire tout de suite : j'ai eu des caméras qui n'étaient pas à l'heure. Plusieurs fois, sur plusieurs installations. Je ne connais personne dans ce métier qui puisse affirmer le contraire, et c'est justement ce qui rend le sujet intéressant. Ce n'est pas une faute d'inattention. C'est le comportement par défaut du matériel, et il faut faire quelque chose de précis pour l'empêcher.
Poser des caméras est facile. Poser une installation dont les images serviront encore à quelque chose six mois plus tard demande de traiter le sujet pour ce qu'il est : un système informatique. Pas un chantier d'électricien avec des objectifs au bout.
Ce n'est pas une image de style. Dans une caméra IP récente, il y a un processeur, un Linux, un serveur web, une pile réseau et un firmware à maintenir. Le capteur est la partie la plus visible et la moins déterminante. C'est pourtant la seule dont on parle en réunion d'avant-projet.
Le NVR n'encode rien
C'est la première chose à comprendre, et elle change tout le dimensionnement. Un NVR ne compresse pas : les caméras lui envoient des flux déjà encodés, et il les recopie sur disque tels quels. Il fait du réseau et de l'indexation, pas de la vidéo. C'est pour ça qu'une machine modeste enregistre trente-deux flux 4K sans transpirer, et qu'elle s'essouffle dès qu'on lui demande de les afficher.
Le nombre de canaux est un argument de vente. La bande passante est une contrainte physique. Un trente-deux voies plafonné à 320 Mb/s, ça fait 10 Mb/s par caméra — le budget d'une 4 MP ordinaire. Avec huit 4K qui filment une rue la nuit, c'est saturé avant d'avoir rempli la moitié des canaux.
Le PoE intégré, ensuite, et il a deux intérêts plutôt qu'un.
Le premier est le câble unique, et c'est un vrai avantage — pas un argument de brochure. Une seule gaine par caméra, pas de prise secteur à faire tirer en hauteur, pas d'alimentation à protéger sur le trajet, une seule pénétration de façade, et un électricien de moins à coordonner. C'est souvent ce qui décide de l'achat, et c'est légitime.
Le second est moins cité et vaut autant : l'enregistreur embarque un commutateur et crée son propre réseau. Les caméras ne sont pas sur le réseau de l'entreprise, et depuis un poste elles ne répondent pas. C'est la meilleure segmentation par défaut du marché — et elle ne demande aucune compétence pour être correcte.
La nuance compte autant que l'avantage. Cette isolation déplace le risque, elle ne le supprime pas. Le commutateur embarqué n'est pas managé, ses ports sont souvent en 10/100, et le NVR devient le seul point à durcir — et le seul à tomber.
ONVIF, et ce qu'il ne garantit pas
ONVIF met tout le monde d'accord sur la découverte, le flux et les événements de base. Sans lui, aucun parc mixte ne serait administrable. Deux remarques quand même.
« Compatible ONVIF » ne veut rien dire. Le terme qui engage est conformant, et la seule preuve est la fiche du produit dans la base des produits conformes, avec sa version de firmware. Une caméra à quarante euros vendue « compatible » sur une place de marché n'y figure en général nulle part.
Et un profil ne couvre que son socle. Le réglage fin de l'image, l'analytique, la gestion du parc restent hors standard. On recevra bien l'événement « intrusion en zone », mais pour dessiner la zone il faudra retourner dans l'interface de la caméra. D'où la deuxième couche, que tout le monde finit par utiliser : l'API du constructeur, VAPIX chez Axis, ISAPI chez Hikvision, SUNAPI chez Hanwha. Aucun fabricant n'a intérêt à normaliser ce qui le distingue.
ONVIF garantit qu'on verra l'image, pas qu'on exploitera la caméra. Le corollaire est une décision d'architecture ordinaire : s'appuyer sur le standard pour tout ce qu'on veut pouvoir remplacer, et sur l'API constructeur seulement là où ça rapporte vraiment — en sachant où passe la frontière.
L'heure
C'est la partie importante. Pas la seule qui ne se rattrape pas : le câblage non plus, une fois les gaines tirées et les façades refermées on ne repasse pas, et c'est bien pour ça que la section précédente existe. Mais une chronologie perdue ne se rattrape même pas au prix d'un chantier. Elle est perdue, et personne ne s'en aperçoit avant d'en avoir besoin.
L'horloge d'une caméra est un quartz. Un quartz ordinaire dérive d'environ une seconde et demie par jour, soit une minute par mois. Et sa réponse à la température n'a qu'un seul côté : dès qu'on s'éloigne des 25 °C, dans un sens comme dans l'autre, l'horloge ralentit. Un enregistreur dans un local technique surchauffé retarde — et il retarde toujours. Trois ans sans y toucher, et on peut avoir une demi-heure d'écart sans que rien ne le signale.
Il y a pire, parce que la dérive au moins est régulière. La pile qui maintient l'horloge à l'arrêt tient quelques années, et sa mort est invisible tant qu'il n'y a pas de coupure de courant. Au premier redémarrage, l'appareil repart d'une date d'usine, souvent le 1ᵉʳ janvier 2000. Les images continuent d'être enregistrées, la recherche par date ne trouve plus rien, et surtout : une rétention à trente jours calcule l'âge d'un enregistrement d'après son horodatage. Un segment estampillé 2000 en a vingt-quatre. Il part à l'effacement tout de suite. On ne perd pas la date, on perd les images.
C'est là que la réponse habituelle arrive, et je l'ai entendue plus souvent qu'à mon tour : « la caméra tourne, non ? » Oui. Elle tourne, elle enregistre, l'image est belle. Et le jour où il faut en tirer quelque chose, elle ne vaut rien.
Le vrai piège n'est pas la seconde, c'est l'heure
La dérive coûte des secondes. Les erreurs de convention coûtent des heures, et elles sont bien plus fréquentes. Le cas que je vois le plus souvent : la case « heure d'été » cochée à la fois sur la caméra et sur le serveur. Le décalage est appliqué deux fois — deux heures d'écart pendant six mois, et rigoureusement juste les six autres. Ça apparaît et ça disparaît aux bascules, et personne ne fait le lien.
Dans le même registre, la nuit du retour à l'heure d'hiver, l'heure locale de 2 h à 3 h existe deux fois. « Vers 02h30 » désigne alors deux instants réels séparés d'une heure. En mars, c'est l'inverse : il y a dans la ligne de temps un trou d'une heure qui n'est pas une panne — mais qui peut très bien être lu comme un effacement par quelqu'un qui ne sait pas.
Sur le matériel d'entrée de gamme, pire : la règle du changement d'heure est écrite en dur dans le firmware. Le jour où un pays la modifie, et le Mexique l'a fait en 2022 avec deux jours de préavis, l'appareil devient faux pendant sept mois par an — en affichant une heure parfaitement plausible.
Ce que ça coûte
Une enquête ne travaille presque jamais sur la seule vidéo. Elle aligne des sources : contrôle d'accès, alarme, journaux réseau, téléphonie, caisse. Et l'intuition commune est ici à l'envers.
La vidéo est en général la plus mauvaise horloge du dossier. Les journaux réseau et les relevés d'opérateur sont synchronisés ; l'enregistreur, presque jamais. Ce sont donc eux qui servent d'ancre, et la vidéo qui se recale dessus. Pas l'inverse.
Sans alignement, impossible de dire si le badge a été passé avant ou après l'apparition de quelqu'un à l'image, et c'est souvent toute la question. Une demande de données couvrant « 22h à 23h » d'après un enregistreur qui retarde de huit minutes rate le créneau réel. Les données existent — elles ne sont simplement pas demandées, et elles seront purgées avant qu'on s'en rende compte.
D'où la règle centrale, qui tient en une phrase : une horloge fausse dont on connaît l'erreur reste utilisable ; une horloge fausse dont on ignore l'erreur détruit la chronologie.
Ce qui m'amène à l'autre erreur, celle que j'ai faite et qui est plus instructive que la première.
Devant un enregistreur qui retardait, j'ai fait ce que fait n'importe qui de consciencieux : j'ai remis l'heure à l'heure. Proprement, tout de suite, avant de toucher au reste. Sauf qu'en corrigeant l'horloge sans avoir noté l'écart, je venais de supprimer la seule information qui permettait de recaler les semaines déjà enregistrées. Le système était juste à partir de cet instant — et définitivement inexploitable avant. Le mécanisme qui produit cette erreur est plus intéressant que l'erreur elle-même : on croit réparer un équipement — alors qu'on manipule une pièce.
On ne remet pas à l'heure un système dont on va exploiter les enregistrements. On mesure l'écart, et on le note, avec l'appareil qui a servi de référence. Remettre l'heure à l'heure détruit l'ancre : après, plus personne ne peut recaler quoi que ce soit.
Mesurer est simple : on filme une horloge de référence. Quelques secondes contenant à la fois l'heure du système et l'heure vraie, et on a une preuve qui reste dans l'image. Contrairement à une note sur un carnet, elle survit à la copie du fichier.
Dernier point, et il est net dans les bonnes pratiques américaines sur l'export vidéo : l'horodatage ne doit pas être gravé dans les pixels. Une incrustation à l'écran n'est pas une donnée, c'est un dessin. Illisible par machine, détruite par un recadrage, muette sur son fuseau, modifiable par n'importe quel outil de montage, et surtout non corrigeable. Si l'enregistreur retarde de douze minutes, l'incrustation retardera de douze minutes pour l'éternité.
Ce qu'on met en place
Rien d'exotique : une source de temps interne unique, et tout le parc dessus, enregistreurs, caméras, serveurs, contrôle d'accès, alarme, pare-feu. Ce qui compte n'est pas l'exactitude absolue mais la cohérence entre systèmes. Deux équipements décalés de la même façon corrèlent parfaitement ; deux équipements exacts mais avec des fuseaux différents sont à une heure l'un de l'autre.
Avec une précaution : vérifier que ça marche vraiment. Un appareil pointé sur un serveur public derrière un pare-feu qui bloque le port échoue en silence. L'interface continue d'afficher « NTP : activé » pendant que l'horloge part en roue libre.
Le réseau, qui ne se bâcle pas
C'est là qu'on redevient informaticien, et c'est là que la plupart des installations se jouent. On n'est pas électriciens : un câble ne se tire pas jusqu'à ce que ça s'allume, il se dimensionne et il se mesure.
Cent mètres, c'est la limite du lien cuivre, pas un objectif. Et c'est un canal complet, cordons de brassage compris. Le PoE chauffe le conducteur, et un câble qui chauffe atténue davantage. Donc cent mètres sur le papier — et moins en vrai.
La règle. Au-delà de cent mètres, on tire de la fibre. Pas de chipotage.
Pas de répéteur PoE, pas de « ça passe, on a testé ». Ces boîtiers ajoutent un point de panne que l'enregistreur n'alimente pas et que la supervision ne voit pas, en haut d'un mât, pour économiser une soudure. Le jour où la caméra tombe, plus personne ne se souvient que la boîte existe.
Pas de sans-fil non plus, ni Wi-Fi ni faisceau hertzien, sauf impossibilité absolue de tirer, et alors les yeux ouverts. D'abord parce qu'un lien radio ne garantit pas la distribution d'un flux continu : il suffit d'un oiseau posé sur l'antenne, d'une grosse averse ou d'une grue arrivée sur le chantier d'en face pour que ça se voie dans les images — au moment précis où on aurait aimé qu'elles soient là. Ensuite parce que c'est exactement le problème du répéteur : un équipement de plus, en hauteur, avec son alimentation, son firmware et son vieillissement.
J'ajoute une chose que j'ai apprise en le payant : un lien radio se valide en juillet et se juge en novembre. Feuillage, pluie, brouillard, chantier voisin. Une recette faite par beau temps ne prouve rien.
Sur le PoE, un seul piège mais il est systématique. Les fiches annoncent une consommation typique et une maximale, et le rapport entre les deux dépasse souvent deux et demi, parce que « typique » veut dire infrarouge éteint et chauffage éteint. Celui qui additionne les valeurs typiques a un budget correct un après-midi de juin — et un commutateur en protection à la première nuit de gel, quand tous les projecteurs et tous les chauffages démarrent ensemble.
Les débits, et la remontée
Un raccourci qui évite les mauvaises surprises : 1 Mb/s en continu, c'est 324 Go sur trente jours. Seize caméras 4 MP en H.265, un mois d'enregistrement continu, ça tourne autour de 15 To. Mais l'important est ailleurs. Selon qu'on retient 2 ou 4 Mb/s par caméra, deux hypothèses également défendables selon la source qu'on consulte, le besoin passe du simple au double. La seule méthode honnête : installer, mesurer une semaine, et dimensionner sur la mesure.
Et puis il y a le calcul que personne ne fait, le débit montant. Les offres restent massivement asymétriques, parce que la voie de retour du câble coaxial occupe une bande étroite dans le spectre. On vend du 200 mégabits descendants avec 10 ou 20 en montée. On fait quoi avec 10 ?
Une fois retirées la marge et l'encapsulation, il reste environ 6 Mb/s utiles. C'est-à-dire : une seule caméra en flux principal H.265, zéro en H.264, ou bien les seize en flux secondaire — c'est-à-dire en vignettes. Il faut choisir, et il faut avoir choisi à la conception. Le flux secondaire n'est pas un pis-aller, c'est la réponse : l'enregistrement de référence reste local, et on ne remonte que ce qu'on peut remonter.
Les codecs, et une habitude qui coûte cher
Le H.265 fait mieux que le H.264, c'est entendu. La norme promet la moitié du débit ; sur des scènes de vidéosurveillance, les mesures publiées par les constructeurs eux-mêmes donnent plutôt 20 à 35 %, parce que le H.265 est conçu pour de la vidéo peu bruitée et très animée, soit l'exact contraire d'un couloir désert filmé de nuit. Vingt-cinq pour cent, c'est déjà beaucoup.
Et pourtant, on trouve encore du H.264 partout, souvent en profil Baseline, c'est-à-dire sans codage arithmétique et sans images bidirectionnelles.
« Pourquoi du Baseline ? — On a toujours fait comme ça. »
L'habitude a une origine parfaitement raisonnable, en 2008. Les documents techniques de l'époque recommandaient explicitement Baseline pour les caméras réseau : puces faibles, clients logiciels limités, et pas d'images bidirectionnelles donc pas de latence. Le raisonnement était juste. Il ne l'est plus depuis longtemps — n'importe quel décodeur actuel encaisse le reste. Laisser Baseline aujourd'hui, c'est payer 10 à 20 % de débit et de disque pour une compatibilité dont plus personne n'a besoin.
La cadence, ensuite. C'est le réglage le plus mal arbitré de tous. À 50 km/h, une voiture parcourt 56 cm entre deux images à 25 par seconde, et 2,31 m à 6 par seconde. À 90 km/h et 6 images, elle avance de plus de quatre mètres entre deux images, davantage que sa propre longueur. Pour un piéton, en revanche, 6 images par seconde suffisent très largement. La cadence n'est un problème que pour les véhicules : un réglage pertinent dans un hall devient inexploitable sur une voie d'accès.
Et le contre-pied, qui se mesure : passer de 6 à 25 images par seconde ne multiplie pas le stockage par quatre, mais par deux environ. Baisser la cadence est un mauvais levier d'économie. On sacrifie beaucoup d'information pour très peu de disque. Les vrais postes de dépense sont la complexité de la scène et le bruit nocturne : du 4K de nuit à 10 images coûte plus cher que du 4K de jour à 30.
La cybersécurité, qui n'est pas une option
Le FBI a publié il y a trois jours une note sur des acteurs qui ciblent spécifiquement caméras et enregistreurs. Elle liste les vulnérabilités recherchées, dont deux datent de 2017 et 2018, et précise que beaucoup n'ont toujours pas été corrigées par les fabricants. Pour l'une d'elles, la recommandation n'est pas de mettre à jour : c'est de remplacer le matériel, faute de correctif existant.
Ce n'est pas nouveau. En 2016, un logiciel malveillant a constitué un parc de plusieurs centaines de milliers d'appareils, essentiellement des enregistreurs et des caméras, en essayant simplement une soixantaine de mots de passe d'usine sur un service d'administration ouvert. Les caméras n'étaient pas la cible. Elles étaient l'arme.
Je n'en démords pas sur trois points.
Aucune caméra joignable depuis Internet. Bannissons le DynDNS et la redirection de port. Le NAT n'a jamais été un mécanisme de sécurité, une redirection n'est pas une protection mais une publication, et le nom en DynDNS transforme une cible d'occasion en cible nommée, réattaquable. L'accès distant passe par un tunnel, point. Les services « cloud » des constructeurs évitent d'ouvrir un port, mais l'équipement ouvre alors lui-même une liaison sortante permanente, ce qui contourne la politique de filtrage. On a déjà vu des dizaines de millions d'appareils exposés parce que leur identifiant de rendez-vous tenait sur vingt bits.
Segmenter, et écrire la matrice de flux. Les caméras parlent à l'enregistreur, l'enregistreur aux caméras, le poste d'exploitation à l'enregistreur et à rien d'autre. Le VLAN dédié est le minimum. Et on bloque aussi les caméras entre elles, c'est le point le plus souvent oublié : sans lui, une caméra compromise en façade recrute les quarante autres en quelques secondes. Pas de route par défaut vers Internet non plus. Sans sortie, un implant n'a ni canal de commande ni exfiltration. En contrepartie, il faut organiser les mises à jour autrement — poussées depuis l'outil de gestion, jamais tirées par la caméra.
Un plan de mise à jour, écrit, avec un responsable. Tous les constructeurs sérieux publient leurs bulletins de sécurité. Le maillon faible n'est pas celui qui les écrit, c'est celui qui ne les lit pas. Sur les caméras je préfère une mise à jour maîtrisée, validée sur un exemplaire pilote, planifiée, avec un retour arrière, à une automatique qu'on ne contrôle pas. Sur le serveur, en revanche, on applique vite : c'est lui qui est exposé.
Et j'ajoute un quatrième point, parce qu'il est propre à ce métier. Une caméra de parking sur un mât, c'est un port réseau à l'extérieur du périmètre. L'attaquant n'a besoin d'aucune faille logicielle — une échelle suffit. Il débranche la caméra, branche son portable, ou mieux pour lui un petit boîtier alimenté par le PoE qu'il laisse dans le caisson en rebranchant la caméra derrière, de sorte que l'image continue d'arriver et que personne ne voit rien.
Dans un bureau, celui qui branche un portable sur une prise murale a déjà franchi un contrôle d'accès. Ici, il n'a rien franchi du tout. C'est ce qui justifie l'authentification des ports par certificat : le commutateur laisse le port fermé tant que l'équipement n'a pas prouvé son identité, et on gagne au passage une alerte quand quelqu'un débranche. Le repli par liste d'adresses MAC ne vaut presque rien : une adresse MAC n'est pas un secret, elle est imprimée sur l'étiquette de la caméra — donc déjà entre les mains de celui qui est monté sur le mât.
Ce que je retiens
- Une caméra est un ordinateur. Firmware, comptes, journaux, segmentation, fin de support. Le capteur est la partie la moins intéressante du produit.
- Le nombre de canaux est un argument de vente, la bande passante une contrainte physique. On mesure avant de promettre, et on n'oublie pas le débit montant.
- Pas de sans-fil, et pas plus de cent mètres de cuivre. Au-delà, la fibre. Tout le reste ajoute en hauteur un point de panne que personne ne supervise.
- Une horloge fausse dont on connaît l'erreur reste utilisable ; une horloge fausse dont on ignore l'erreur détruit la chronologie. Donc on ne remet pas à l'heure : on mesure l'écart, et on l'écrit.
Le plus frustrant, dans tout ça, c'est que la partie qui décide de la valeur d'une installation ne coûte rien. Un serveur de temps interne, une ligne dans la matrice de flux, un écart mesuré le jour de la réception. Les téraoctets et les mégapixels se rattrapent toujours ; l'heure d'un enregistrement, jamais.