DeepCamera : une plateforme de compétences pour caméras, entre JSONL sur stdin et application compagnon

Le problème : un flux vidéo n'est pas un événement

Une caméra produit des images en continu. Un système de sécurité, lui, a besoin de phrases : quelqu'un est passé, un colis a été déposé, une plaque a été lue. Le README de DeepCamera présente le projet comme une plateforme de compétences qui apporte ces capacités à des caméras existantes, en s'appuyant sur des modèles comme Qwen, DeepSeek, SmolVLM, LLaVA ou YOLO26. La cible annoncée est double : les développeurs qui veulent composer leurs propres compétences, et les utilisateurs de Mac Mini ou d'AI PC qui veulent faire tourner l'inférence en local. Le point de conception intéressant n'est pas la liste des modèles, c'est le découpage : chaque capacité est un module autonome avec son propre modèle et ses propres paramètres. Cela déplace la difficulté. On ne choisit plus un logiciel de vidéosurveillance monolithique, on assemble des briques. En contrepartie, c'est à l'utilisateur de comprendre comment ces briques communiquent, ce que le dépôt décrit dans docs/skill-development.md et docs/skill-params.md.

Le protocole JSONL : un cadre lit une image, écrit des détections

Le mécanisme central est décrit sans ambiguïté dans le README : toutes les compétences de détection et de segmentation utilisent le même protocole JSONL sur stdin et stdout. Aegis écrit une image dans un volume partagé, envoie un événement frame sur stdin, puis lit des detections sur stdout. Du point de vue de l'orchestrateur, chaque skill de détection est interchangeable. C'est un choix d'architecture qui a des conséquences pratiques. Un skill n'est pas un service réseau à interroger, ni une bibliothèque à lier : c'est un processus qui consomme des lignes JSON et en produit. On peut donc l'écrire dans n'importe quel langage, le tester en lui envoyant des lignes à la main, et le remplacer sans toucher au reste de la chaîne. Le schéma du README montre aussi un Frame Governor à 5 FPS en amont du protocole. Ce plafond est un paramètre de conception, pas un détail : il fixe la cadence à laquelle les compétences reçoivent des images, et donc la charge que chaque modèle doit absorber. Le dépôt ne donne pas, dans les éléments fournis, de mesure de ce que ce plafond implique en termes de détection manquée sur un objet rapide. C'est une zone où la documentation reste silencieuse.

env_config.py : une couche matérielle partagée

Le README décrit une couche d'environnement matériel, env_config.py, placée dans skills/lib/. Son rôle annoncé est double : détecter le matériel et optimiser les modèles en conséquence. Le schéma de flux précise la correspondance : NVIDIA vers TensorRT, Apple Silicon vers CoreML, Intel vers OpenVINO IR, AMD et CPU vers ONNX. Les compétences Coral suivent un chemin distinct, avec ai-edge-litert et libedgetpu, et un repli sur CPU en l'absence d'Edge TPU. Ce découpage répond à un vrai problème : un même modèle YOLO ne s'exécute pas de la même façon selon le matériel, et écrire cette logique une fois pour toutes évite de la dupliquer dans chaque skill. La feuille de route mentionne une installation sensible au GPU, au NPU et au CPU des AI PC, avec conversion des modèles vers le format optimal. Il faut noter ce que cela implique : la conversion de modèles est une étape qui peut échouer ou produire des résultats différents selon le backend. Le dépôt ne fournit pas, dans le matériel disponible, de tableau comparant la précision d'un même modèle entre TensorRT, CoreML et ONNX. Toute personne qui dépend d'un seuil de détection précis doit donc valider ce point par elle-même sur son matériel.

Installer : deux chemins, dont un seul est détaillé

Le README ne donne pas de séquence docker run ni de commande d'installation en ligne de commande. Il oriente vers SharpAI Aegis, présenté comme l'application de bureau compagne, qui configure l'environnement, les compétences et le pipeline à la place de l'utilisateur, sans Docker ni CLI manuel. Le seul identifiant d'installation explicite dans les éléments fournis est le paquet PyPI sharpai-hub, référencé par le badge du dépôt. Les chemins de fichiers cités dans le README constituent le reste de ce qu'on peut vérifier : skills.json comme registre indexant toutes les compétences pour la découverte programmatique, skills/lib/env_config.py pour la détection matérielle, docs/skill-development.md pour le protocole de communication, docs/skill-params.md pour les paramètres de plateforme. Un lecteur qui refuse l'application de bureau se retrouve donc face à un dépôt qui documente le contrat entre composants mais pas une procédure d'amorçage manuelle complète. C'est un manque réel, pas une impression : la documentation décrit comment écrire un skill, pas comment démarrer la plateforme sans Aegis.

Le catalogue : beaucoup de cases vides

Le tableau du catalogue sépare dix catégories et une vingtaine de compétences, avec trois états : prêt, en test, planifié. Les compétences marquées prêtes concernent la détection YOLO 2026, sa variante Coral Edge TPU, le benchmark home-security, l'estimation de profondeur pour l'anonymisation, la segmentation SAM2 et l'annotation de jeux de données. La détection OpenVINO est en test. Sont planifiés : reconnaissance faciale, lecture de plaques, entraînement de modèles, automatisation MQTT, webhook, déclencheur Home Assistant, et le pont Home Assistant. Autrement dit, les briques qui relient DeepCamera à un écosystème domotique existant ne sont pas encore livrées. Pour un lecteur qui veut décider, cette distinction compte plus que la longueur de la liste. La feuille de route annonce par ailleurs 19 compétences réparties sur 10 catégories, en expansion, ce qui suggère que le catalogue va bouger. Le README ne donne pas de date d'arrivée pour les éléments planifiés. Un déploiement qui repose sur ha-trigger ou homeassistant-bridge est donc, en l'état des informations disponibles, un pari sur une feuille de route.

Le benchmark HomeSec et l'anonymisation par profondeur

Deux compétences méritent un examen séparé parce qu'elles ne détectent rien. home-security-benchmark est décrit comme une suite d'évaluation de 143 tests pour mesurer la performance de modèles de langage et de vision sur des tâches de sécurité domestique. C'est un outil de comparaison, utile si vous hésitez entre plusieurs VLM locaux et voulez une base de mesure plutôt qu'une impression. Le chiffre de 143 tests vient du README ; le contenu exact des tests n'est pas détaillé dans les éléments fournis. depth-estimation, classée dans la catégorie vie privée, produit une carte de profondeur en temps réel pour anonymiser un flux tout en préservant l'activité détectable. L'idée est cohérente avec le positionnement local du projet : si l'inférence ne quitte pas la machine, le risque se déplace vers ce qui est stocké ou transmis ensuite, et une transformation de profondeur réduit ce qui est identifiable dans les enregistrements. Reste une question que le matériel ne tranche pas : à quelle résolution la carte de profondeur reste-t-elle exploitable pour un modèle de détection en aval ? Le README ne donne pas de chiffre.

Ce qui manque, et à quoi cela ressemble ailleurs

DeepCamera n'est pas un NVR prêt à l'emploi. C'est un cadre d'exécution de compétences, avec une application de bureau qui l'orchestre et un agent conversationnel branché sur Discord, Telegram ou Slack. La différence avec une chaîne classique type Frigate est structurelle. Frigate organise la détection autour d'un serveur unique, avec une configuration déclarative et un stockage d'événements intégré ; on installe une chose, on la configure, elle tourne. DeepCamera fait l'inverse : le cœur est un contrat de communication, et la valeur vient des skills que vous ajoutez. Ce choix paie si vous avez un besoin que personne n'a prévu, par exemple une transformation d'image spécifique ou un modèle maison. Il coûte quand vous voulez simplement que ça marche : la qualité dépend du skill, pas de la plateforme, et un skill planifié ne vous sert à rien aujourd'hui. Le README ne fournit pas de comparaison avec d'autres projets, et rien dans les éléments disponibles ne permet de dire comment DeepCamera se comporte face à une charge de plusieurs caméras simultanées.

Maintenance, licence et coût de mise à jour

Le dépôt est publié sous licence MIT, ce qui autorise la modification et la redistribution avec conservation de l'avis de licence ; ce n'est pas un avis juridique et les obligations exactes doivent être lues dans le fichier LICENSE. Le projet n'est pas archivé et la dernière poussée sur la branche master date du 18 juin 2026, ce qui indique une activité récente. Les versions récentes montrent un rythme irrégulier : v2026.3 en mars 2026, Aegis en février 2026, puis un saut jusqu'à v3.4.3 en août 2022. Cette rupture de numérotation signifie qu'un lecteur qui suit les versions doit se fier aux notes de version plutôt qu'à l'ordre des numéros. Le coût de maintenance réel se situe ailleurs : les compétences embarquent leurs propres modèles et leurs propres paramètres, donc chaque mise à jour de modèle ou de framework d'accélération (TensorRT, CoreML, OpenVINO, ONNX) se répercute dans les skills concernés. La couche env_config.py centralise la détection, mais pas les conversions. Sur un parc de plusieurs machines hétérogènes, cette charge est à prévoir.

Conclusion éditoriale

DeepCamera convient à un développeur qui veut brancher des modèles de vision locaux sur des caméras et qui accepte d'écrire ou d'adapter un skill lui-même, ainsi qu'à un utilisateur de Mac Mini ou d'AI PC prêt à passer par SharpAI Aegis pour éviter Docker et la ligne de commande. Il ne convient pas à qui cherche une chaîne CCTV complète et stable : sur les dix catégories du catalogue, seules quelques compétences sont marquées prêtes, le reste étant en test ou planifié. Avant tout déploiement, vérifiez le contenu réel de skills.json et l'état du skill dont vous dépendez, puis lisez docs/skill-development.md pour confirmer que le protocole correspond à votre version du dépôt.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. SharpAI/DeepCamera on GitHub