Caméras IA
détecter, reconnaître, retrouver

Le problème n'est pas l'image, c'est la recherche

Sur une installation classique, une caméra enregistre vingt-quatre heures sur vingt-quatre et personne ne regarde. Le jour où il faut retrouver une livraison manquante ou une intrusion, quelqu'un fait défiler des heures de vidéo. C'est là que le temps part, et c'est là que la détection change les choses.

Depuis deux ans, la question a changé de nature. On ne demande plus seulement « la caméra a-t-elle vu quelque chose », mais « peut-on retrouver la séquence où une personne portait ce vêtement, est entrée par cette porte, ou a garé ce véhicule ». Cette promesse est tenable, à condition de distinguer quatre niveaux qui n'ont ni le même coût, ni le même risque juridique.

Quatre niveaux, à ne pas confondre

Les deux premiers niveaux sont de la commodité. Les deux derniers sont des traitements de données personnelles, et le dernier peut glisser vers la biométrie sans qu'on s'en aperçoive. C'est toute la différence entre un outil qui fait gagner du temps et un dispositif qu'on ne peut pas déployer.

Ce que la caméra fait déjà toute seule

Les gammes récentes classent sur l'appareil : personne, véhicule, animal, colis. Une recherche par type et par plage horaire remplace des heures de défilement, et les zones d'intérêt évitent de déclencher sur la route qui passe derrière.

Le calcul reste dans la caméra ou dans le contrôleur, pas dans un cloud tiers. C'est ce qui permet de tenir une promesse simple : les images ne quittent pas le bâtiment, et l'installation continue de fonctionner si la ligne tombe.

Ce que les modèles ajoutent, et où ils tournent

Chez Ubiquiti, la répartition est documentée et elle surprend souvent en rendez-vous. Selon le modèle de caméra, la reconnaissance faciale et la lecture de plaques sont natives, ou nécessitent un boîtier d'inférence. Un article d'aide de l'éditeur donne la matrice complète : les séries G6 et AI font la reconnaissance de visage et de plaque en natif, les séries G4 et G5 y accèdent avec un AI Port, et le port ajoute aussi la classification (type et couleur de véhicule) sur des caméras G3 ou ONVIF.

Un second boîtier, l'AI Key, ne fait pas de détection : il retravaille les détections envoyées par les caméras. Il ajoute le type et la couleur du vêtement, les accessoires, la recherche en langage naturel, la transcription de la parole et une amélioration du visage. Ses limites sont chiffrées par l'éditeur : environ 1 000 détections par heure et une file de 200 événements, au-delà les détections sont écartées. Une caméra qui voit beaucoup de monde sature donc ce boîtier, et le résultat arrive en différé.

Ce détail change une architecture. Si la reconnaissance doit être immédiate, elle doit être faite par la caméra ou par un AI Port, pas par un boîtier asynchrone. Si elle sert à enquêter après coup, un traitement différé suffit et coûte moins cher.

Sous le capot, quatre familles de modèles

Il n'y a pas de magie, et le vocabulaire aide à poser les bonnes questions à un intégrateur.

• Détection d'objets. Des réseaux de type YOLO, entraînés à encadrer ce qu'ils reconnaissent. Rapides, ils tournent sur une caméra ou un boîtier, et ils se trompent surtout sur les objets petits, flous ou partiellement cachés.
• Ré-identification. Un modèle transforme la silhouette d'une personne en un vecteur, comparable d'une caméra à l'autre. C'est ce qui permet de suivre un trajet sans reconnaître un visage : plus respectueux, mais sensible aux changements de vêtement.
• Texte et image dans le même espace. Les modèles de la famille CLIP apprennent à comparer une phrase et une image. On peut alors demander « veste rouge avec un logo blanc » et obtenir un classement de séquences. Les variantes spécialisées sur l'habillement existent et sont publiées, par exemple FashionCLIP ou OpenFashionCLIP, entraînées sur des données de mode.
• Reconnaissance faciale. Un gabarit numérique est calculé à partir du visage, puis comparé à une base. C'est une donnée biométrique, et c'est le seul des quatre niveaux qui soit, en pratique, interdit sans base légale.

Le cas concret : retrouver une marque sur un vêtement

C'est une demande récurrente en commerce et en hôtellerie : « la personne portait le blouson de telle marque, retrouvez-moi la séquence ». Techniquement, cela ressemble à une recherche par attribut, pas à une reconnaissance de personne. Trois étapes comptent.

Découper, pas agrandir d'abord. On extrait des images des détections, on recadre sur la personne, et on indexe. Le logo est un petit objet dans une grande image : c'est le cadrage qui décide si le détail existe encore.

Chercher par similarité, puis trier à la main. Un index d'embeddings classe les séquences par ressemblance. Il rend les vingt candidats les plus proches, pas une réponse. Un opérateur valide, et c'est cette validation qui fait la valeur du résultat.

Se méfier de l'agrandissement. Un logo qui fait moins de deux pixels de large sur l'image d'origine n'est plus dans le fichier : aucun logiciel ne le retrouvera. Et les modèles d'agrandissement par apprentissage ne restituent pas le détail manquant, ils en inventent un plausible. Les analyseurs vidéo le disent explicitement, et l'éditeur d'un des logiciels d'amélioration les plus connus déconseille lui-même l'usage forensic. Une image « améliorée » n'est pas une preuve, c'est une illustration.

Améliorer la qualité sans fabriquer du faux

Il y a une manière honnête d'améliorer une image, et une manière qui pose problème.

La règle que nous appliquons : conserver l'original intact, journaliser chaque opération, et présenter les deux images ensemble. Un rapport qui ne montre que la version améliorée ne vaut rien, même si le résultat est spectaculaire.

Piloter UniFi par l'API, proprement

Le contrôleur expose une API d'intégration officielle, sous /proxy/protect/integration/v1, authentifiée par une clé (X-API-KEY) créée dans les réglages du contrôleur. La documentation est publiée sur developer.ui.com. On y trouve l'identité du contrôleur, la liste des caméras, les instantanés, les flux RTSPS et les événements en direct.

Pour l'historique, en revanche, c'est l'API privée du contrôleur qui répond, avec une session utilisateur et un jeton CSRF. Elle n'est pas documentée et bouge d'une version à l'autre : c'est un choix assumé, à isoler dans une couche qu'on peut casser sans casser le reste. Deux règles nous ont évité des soirées perdues.

• Une clé, un usage. La clé hérite des droits de l'administrateur qui l'a créée. Une clé dédiée, en lecture, pour l'intégration, et une autre pour les opérations d'administration.
• Interroger par fenêtre et par caméra. Une requête d'événements sans filtre de type renvoie des tranches incohérentes sur certaines versions. Le filtre se met côté contrôleur, pas côté client.

Ce que nous construisons autour est volontairement modeste : un collecteur qui récupère les détections, les vignettes et les horodatages, les range dans une base locale, et calcule des embeddings pour la recherche par attribut. Aucune image ne part chez un tiers, et l'accès est nominatif.

Le cadre légal, sans détour

Vidéosurveiller un lieu de travail ou un espace recevant du public suppose une information claire des personnes filmées, une finalité définie et une durée de conservation proportionnée. Sur la reconnaissance faciale, la position de la CNIL est constante : les gabarits faciaux sont des données biométriques (article 4-14 du RGPD), donc des données sensibles au sens de l'article 9, dont le traitement est en principe interdit et suppose une exception prévue par le droit. La CNIL précise aussi que la détection de visage, qui constate une présence sans identifier, n'est pas la reconnaissance, qui identifie. La confusion entre les deux est fréquente en réunion, et elle n'est pas anodine.

Conséquences pratiques pour un établissement : une analyse d'impact est nécessaire dès qu'on touche à ces traitements, la reconnaissance faciale n'a pas sa place dans un commerce sans base légale, et l'alternative honorable est la recherche par attributs non identifiants (vêtement, gabarit, heure, porte), avec validation humaine et journal d'accès.

Ce qu'on installe, et ce qu'on ne promet pas

Des caméras UniFi et un contrôleur sur site, avec enregistrement local. Le contrôleur sert de point d'accès distant sans ouvrir de port sur le routeur, et le parc se supervise par la même supervision que le reste du réseau, disque plein compris.

Nous ne promettons pas de « retrouver n'importe qui » : une caméra mal placée, un contre-jour ou un logo trop petit ne se corrigent pas au logiciel. Nous promettons une recherche qui divise le temps d'enquête, une conservation maîtrisée, et des images qui restent dans le bâtiment.

Ce que ça change en pratique

Sur une installation de commerce ou d'hôtel, la recherche d'un événement passe de « il faut visionner la nuit » à « filtrer les passages entre 2 h et 4 h, puis trier vingt vignettes ». Le gain n'est pas la caméra : il est dans le temps qu'on ne passe plus à chercher, et dans la possibilité de documenter ce qu'on a trouvé.

La frontière est claire. Un outil qui aide un opérateur à retrouver une séquence est un progrès. Un dispositif qui identifie des personnes sans base légale est un problème, et il le restera même s'il fonctionne très bien.