Frigate 0.18 enterre le YAML et impose la configuration par interface, au prix d’une vraie migration
Le 12 septembre 2026, Frigate 0.18, le NVR d’auto-hébergement à détection d’objets par IA, a remplacé son fichier YAML par une configuration complète via l’interface et ajouté des profils et un GenAI multi-fournisseurs. Sauvegardez votre configuration et frigate.db, vérifiez les changements cassants, puis migrez si vous voulez la config par interface.
12 septembre 2026. Frigate publie sa version 0.18.0, une mise à jour majeure de son NVR auto-hébergé à détection d’objets par IA. 36 000 étoiles GitHub. La mesure de la communauté qui le fait tourner, souvent aux côtés de Home Assistant. Août 2026. La fermeture de DeGirum, dont le détecteur est retiré de cette version. Pourquoi c’est important : Frigate bascule d’un monde « YAML d’abord » à une configuration complète par interface, et cette bascule n’est pas gratuite — c’est une migration, pas une mise à jour de routine.
Frigate est l’un des projets d’auto-hébergement les plus installés pour la vidéosurveillance locale : il détecte personnes, véhicules et animaux avec des modèles d’IA exécutés sur le CPU, le GPU ou un accélérateur dédié, sans envoyer une seule image vers le nuage. Sa force a longtemps reposé sur un fichier config.yml unique, précis mais exigeant. La 0.18 change ce contrat.
La configuration par interface devient la voie principale
Le changement de fond est l’arrivée d’une configuration complète par interface, appelée Settings. Elle couvre chaque section du fichier — caméras, détecteurs, mouvement, enregistrement, revue, GenAI, recherche sémantique, reconnaissance faciale, lecture de plaques, réseaux, authentification — avec validation champ par champ, descriptions intégrées et liens vers la documentation.
L’interface distingue la configuration globale de la configuration par caméra, permet de surcharger une valeur globale sur une caméra et de revenir aux défauts à tout moment. Elle signale les modifications non enregistrées, propose un bouton « Save All » qui récapitule les changements, et indique quels champs exigent un redémarrage — avec un bouton de redémarrage en un clic.
Le point crucial pour les équipes qui automatisent : le YAML manuel reste entièrement supporté. Frigate n’abandonne pas les utilisateurs qui versionnent leur configuration, mais il fait de l’interface la voie recommandée. C’est le même virage que d’autres projets d’auto-hébergement — Dynacat, mentionné dans la même semaine par selfh.st, a fait le même pas vers la configuration sans YAML.
Les profils, ou comment changer de comportement sans redémarrer
La seconde nouveauté structurante, ce sont les profils. Ils permettent de définir des surcharges nommées par-dessus la configuration de base d’une caméra, et de basculer entre elles sans redémarrer — détection, mouvement, enregistrement, notifications, zones, objets, reconnaissance faciale, lecture de plaques, audio, vue birdseye.
L’usage réel est immédiat. Une caméra de jardin peut passer d’un profil « nuit » à un profil « vacances » par simple commande, le profil actif étant persisté entre les redémarrages et pilotable depuis l’interface ou par le topic MQTT frigate/profile/set. Pour une maison déjà câblée en Home Assistant, cela signifie que des automatisations peuvent changer le comportement de la surveillance selon l’heure, la présence ou une alarme.
Le GenAI devient multi-fournisseurs, et le stockage change de format
La partie GenAI est restructurée en profondeur. Là où un fournisseur unique était configuré globalement, Frigate 0.18 accepte une carte de fournisseurs, chacun avec un rôle défini — descriptions d’objets, résumés de revue, embeddings, chat. Un fournisseur llama.cpp dédié fait son entrée, avec sondage automatique du modèle, ce qui ouvre la porte à un GenAI 100 % local.
La migration de l’existant est automatique pour les configurations simples, mais le changement de format de snapshots est, lui, définitif. Frigate cesse d’enregistrer les JPEG annotés sur le disque au profit d’un WebP propre unique. Les utilisateurs qui dépendaient de ces .jpg annotés doivent passer par l’endpoint /api/events/<id>/snapshot.jpg, qui accepte désormais les paramètres timestamp, bounding_box et crop.
Les changements cassants à vérifier avant de migrer
La 0.18 est l’une des versions les plus lourdes en breaking changes depuis longtemps. La liste mérite une lecture attentive avant tout docker pull :
- GenAI : la clé globale
genaidevient une carte de fournisseurs avec un champroles; les configs existantes sont migrées automatiquement. - Snapshots : plus de JPEG annotés, le paramètre
clean_copydisparaît, la qualité par défaut passe de 70 à 60. - Zones et masques : le format ajoute les champs
enabledetfriendly_name, avec migration automatique. - GPU Intel : les statistiques ne passent plus par
intel_gpu_topmais lisent les compteurs DRM du noyau — plus deCAP_PERFMON, de mode privilégié ni deperf_event_paranoid, mais un noyau Linux 6.5 ou plus récent est requis. - FFmpeg 8 : le transcodage matériel de go2rtc demande un petit ajustement de configuration ; FFmpeg 5 est déprécié.
- Détecteurs : DeGirum est retiré (l’éditeur a cessé ses activités le 1ᵉʳ août 2026), DeepStack est déprécié et disparaîtra en 0.19.
# Sauvegarder la configuration et la base avant migration vers Frigate 0.18
docker stop frigate
cp /path/to/config/config.yml /path/to/config/config.yml.bak
cp /path/to/config/frigate.db /path/to/config/frigate.db.bak
# Mettre à jour l'image et relancer (les configs simples sont migrées automatiquement)
docker pull ghcr.io/blakeblackshear/frigate:0.18.0
docker start frigate
docker logs -f frigate # surveiller les éventuels échecs de migrationLa règle est simple : sauvegardez config.yml et frigate.db avant toute chose, puis laissez le migrateur faire son travail sur une copie, pas sur votre instance de production.
Ce que la 0.18 dit de l’auto-hébergement
Frigate 0.18 illustre un mouvement plus large. Les applications d’auto-hébergement qui ont grandi avec un public technique découvrent une seconde génération d’utilisateurs qui ne veut plus écrire de YAML, mais qui exige le même niveau de contrôle. La réponse n’est pas l’abandon du fichier, mais la coexistence : l’interface pour la majorité, le fichier pour l’automatisation.
Cette maturité a un corollaire. Plus un projet devient « configurable depuis l’interface », plus ses migrations ressemblent à celles d’un logiciel commercial — avec des changements de format, des dépréciations et des dates de fin de support. Le maintien d’une instance Frigate demande désormais la même discipline de sauvegarde et de journal de version qu’un service en production.
Verdict
Frigate 0.18 est une bonne version, mais c’est une migration, pas une mise à jour. Si votre configuration actuelle dépend des JPEG annotés, d’un GPU Intel sur un noyau ancien ou du détecteur DeepStack, restez sur 0.17 le temps de planifier. Si vous voulez la configuration par interface, les profils et un GenAI multi-fournisseurs, sauvegardez config.yml et frigate.db, vérifiez la liste des changements cassants, puis migrez sur un environnement de test avant la production. Dans tous les cas, ne laissez pas une version 0.17 vieillir trop longtemps : DeepStack et FFmpeg 5 disparaîtront en 0.19, et le saut ne fera que s’alourdir.