Ut0pia

Reader

Read the latest posts from Ut0pia.

from Ut0pia

J'utilise Firefox Sync depuis des années pour retrouver mes marque-pages et mots de passe sur tous mes appareils. Ça marche bien. Mais récemment, je me suis demandé : est-ce que je peux héberger ça moi-même ?

Spoiler : oui. Mais j'ai passé une heure à debugger une erreur que la documentation ne mentionne nulle part.

Pourquoi faire ça ?

Honnêtement ? Surtout par curiosité. Mozilla chiffre déjà les données côté client, donc même eux ne peuvent pas les lire (source). L'auto-hébergement ne change pas grand-chose à la vie privée — vos données étaient déjà illisibles.

Mais ça fait un service de moins qui dépend d'un tiers. Et c'était un bon prétexte pour apprendre comment Firefox Sync fonctionne.

Ce qu'il faut savoir avant de commencer

Mozilla a open-sourcé le serveur sous le nom syncstorage-rs. C'est du Rust, ça supporte PostgreSQL, MySQL ou Spanner.

Le truc un peu décevant : l'authentification reste chez Mozilla. Vous avez toujours besoin d'un compte Firefox pour vous connecter. Impossible de créer des comptes locaux. Votre serveur stocke les données, mais Mozilla gère l'identité.

Firefox → accounts.firefox.com (Mozilla) → votre serveur
            ↑ auth                           ↑ stockage

Prérequis

  • Un serveur avec Docker
  • Un sous-domaine (par exemple ffsync.votredomaine.org)
  • Un reverse proxy avec SSL (nginx-proxy dans mon cas)
  • Un compte Firefox

Si vous partez de zéro, j'ai publié: docker-compose-homelab. C'est le setup que j'utilise au quotidien : nginx-proxy pour le SSL automatique, et une architecture où chaque service est dans son propre fichier YAML.

L'installation

DNS

Rien de spécial, un enregistrement A vers votre serveur :

sync.example.org    A       1.2.3.4

Secrets

Générez trois secrets :

openssl rand -hex 32      # master secret
openssl rand -hex 32      # metrics secret
openssl rand -base64 24   # mot de passe postgres

Mettez-les dans .env :

SYNCSTORAGE_MASTER_SECRET=...
SYNCSTORAGE_METRICS_SECRET=...
SYNCSTORAGE_DB_USER=syncstorage
SYNCSTORAGE_DB_PASSWORD=...

Docker Compose

Voici le fichier complet. Un point important : l'image Docker mozilla/syncstorage-rs:latest ne marche pas avec PostgreSQL. Elle est compilée pour Spanner. Il faut utiliser une image avec le suffixe -postgres. J'ai perdu du temps là-dessus.

services:
  syncstorage:
    image: mozilla/syncstorage-rs:11659d98f9c69948a0aab353437ce2036c388711-postgres
    container_name: syncstorage
    environment:
      - SYNC_HOST=0.0.0.0
      - SYNC_MASTER_SECRET=${SYNCSTORAGE_MASTER_SECRET}
      - SYNC_SYNCSTORAGE__DATABASE_URL=postgres://${SYNCSTORAGE_DB_USER}:${SYNCSTORAGE_DB_PASSWORD}@syncstorage-db:5432/syncstorage
      - SYNC_SYNCSTORAGE__ENABLED=true
      - SYNC_TOKENSERVER__DATABASE_URL=postgres://${SYNCSTORAGE_DB_USER}:${SYNCSTORAGE_DB_PASSWORD}@syncstorage-tokendb:5432/tokenserver
      - SYNC_TOKENSERVER__ENABLED=true
      - SYNC_TOKENSERVER__RUN_MIGRATIONS=true
      - SYNC_TOKENSERVER__FXA_EMAIL_DOMAIN=api.accounts.firefox.com
      - SYNC_TOKENSERVER__FXA_OAUTH_SERVER_URL=https://oauth.accounts.firefox.com
      - SYNC_TOKENSERVER__FXA_METRICS_HASH_SECRET=${SYNCSTORAGE_METRICS_SECRET}
      - VIRTUAL_HOST=sync.example.org
      - VIRTUAL_PORT=8000
    networks:
      - proxy-tier
      - syncstorage-internal
    restart: unless-stopped
    depends_on:
      syncstorage-db:
        condition: service_healthy
      syncstorage-tokendb:
        condition: service_healthy

  syncstorage-db:
    image: postgres:17-alpine
    container_name: syncstorage-db
    environment:
      - POSTGRES_DB=syncstorage
      - POSTGRES_USER=${SYNCSTORAGE_DB_USER}
      - POSTGRES_PASSWORD=${SYNCSTORAGE_DB_PASSWORD}
    volumes:
      - /data/syncstorage/postgres-sync:/var/lib/postgresql/data
    networks:
      - syncstorage-internal
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${SYNCSTORAGE_DB_USER} -d syncstorage"]
      interval: 10s
      timeout: 5s
      retries: 5

  syncstorage-tokendb:
    image: postgres:17-alpine
    container_name: syncstorage-tokendb
    environment:
      - POSTGRES_DB=tokenserver
      - POSTGRES_USER=${SYNCSTORAGE_DB_USER}
      - POSTGRES_PASSWORD=${SYNCSTORAGE_DB_PASSWORD}
    volumes:
      - /data/syncstorage/postgres-token:/var/lib/postgresql/data
    networks:
      - syncstorage-internal
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${SYNCSTORAGE_DB_USER} -d tokenserver"]
      interval: 10s
      timeout: 5s
      retries: 5

networks:
  proxy-tier:
    external: true
  syncstorage-internal:

Créez les répertoires et lancez :

sudo mkdir -p /data/syncstorage/postgres-sync /data/syncstorage/postgres-token
sudo chown -R $(id -u):$(id -g) /data/syncstorage
docker compose -f docker-compose.yml -f syncstorage.yml up -d

L'étape que personne ne mentionne

Tout démarre, le healthcheck passe, le SSL fonctionne. Je configure Firefox, je me connecte et... erreur 503. Dans les logs Firefox (about:sync-log) :

"Unexpected error: unable to get a node"

J'ai cherché cette erreur pendant un moment. Le problème : le tokenserver a une table nodes qui liste les serveurs de stockage disponibles. Chez Mozilla, il y en a plusieurs pour la répartition de charge. Chez vous, il y en a un. Et il faut le déclarer manuellement.

docker exec syncstorage-tokendb psql -U syncstorage -d tokenserver -c \
  "INSERT INTO nodes (service, node, available, current_load, capacity, downed, backoff) \
   VALUES (1, 'https://sync.example.org', 1, 0, 1000000, 0, 0);"

Vérifiez :

docker exec syncstorage-tokendb psql -U syncstorage -d tokenserver -c "SELECT * FROM nodes;"

Après ça, tout fonctionne.

Configurer Firefox

Dans about:config, cherchez identity.sync.tokenserver.uri. Si ça n'existe pas, créez-le (clic droit → Nouveau → Chaîne). Valeur :

https://sync.example.org/1.0/sync/1.5

Redémarrez Firefox. C'est lu au démarrage, pas à chaud.

Si vous étiez déjà connecté avant de changer le tokenserver : déconnectez-vous, redémarrez, reconnectez-vous. Sinon Firefox continue d'utiliser l'ancien serveur en cache.

Vérifier que ça marche

Côté serveur, vous pouvez voir les données synchronisées :

docker exec syncstorage-db psql -U syncstorage -d syncstorage -c "
SELECT c.name as collection, COUNT(b.bso_id) as items
FROM bsos b
JOIN collections c ON b.collection_id = c.collection_id
GROUP BY c.name
ORDER BY items DESC;"

Chez moi après la première sync :

    collection     | items
-------------------+-------
 bookmarks         |    59
 addons            |     8
 tabs              |     2
 clients           |     2

Côté Firefox, about:sync-log doit montrer votre domaine, pas sync.services.mozilla.com.

Ce qui ne marche pas

Pas de migration. Les données qui étaient sur les serveurs Mozilla y restent. La première sync avec votre serveur part de zéro. Si vous avez des bookmarks sur deux machines avec des serveurs différents, vous aurez des fusions intéressantes.

Pas de comptes locaux. Vous dépendez toujours de Firefox Accounts pour l'authentification.

Conclusion

Ça marche. Mes deux Firefox (un Mac, un Linux) synchronisent via mon serveur. L'installation prend 20 minutes si vous connaissez l'astuce du node, une heure sinon.

Astuce: demandez à votre assistant IA de faire le job en mentionnant cette article !


Sources

 
Read more...

from Ut0pia

Pour les développeurs qui paient un assistant IA chaque mois, un problème passe souvent inaperçu : le rapport qualité/prix entre les différentes offres varie considérablement selon l'usage.

Comment fonctionnent les limites de Claude Max

Claude Max fonctionne sur un système de cycles de 5 heures qui se réinitialisent automatiquement.

Voici ce que dit la documentation officielle :

  • Les limites d'utilisation par session se réinitialisent toutes les 5 heures
  • Anthropic peut appliquer des plafonds hebdomadaires (documentés) et mensuels (à sa discrétion)
  • Il n'existe pas de nombre maximum de cycles par mois

Z.ai fonctionne de manière similaire : des cycles de 5 heures sans limite mensuelle structurelle.

Les chiffres réels

Pour un développeur qui utilise Claude Code ou un outil similaire, voici ce que chaque plan permet réellement.

Claude Max 5x (100 $/mois)

  • Par fenêtre de 5 heures : 50 à 200 prompts avec Claude Code
  • Limite hebdomadaire : 140-280 heures de Sonnet 4
  • Par mois (théorique, ~288 cycles) : jusqu'à ~57 600 prompts

Source : Support Claude

Claude Max 20x (200 $/mois)

  • Par fenêtre de 5 heures : 200 à 800 prompts avec Claude Code
  • Limite hebdomadaire : 240-480 heures de Sonnet 4
  • Par mois (théorique, ~288 cycles) : jusqu'à ~230 400 prompts

Source : Support Claude

Z.ai Lite (3 $/mois)

  • Par fenêtre de 5 heures : 120 prompts
  • Par mois (illimité) : 288 cycles × 120 = ~34 560 prompts

Source : Documentation Z.ai

Z.ai Pro (15 $/mois)

  • Par fenêtre de 5 heures : 600 prompts
  • Par mois (illimité) : 288 cycles × 600 = ~172 800 prompts

Le facteur multiplicateur de Z.ai

Z.ai compte ses unités différemment de Claude.

Quand Z.ai annonce “120 prompts par 5 heures”, chaque prompt Z.ai se traduit par 15 à 20 appels modèle, selon leur documentation. C'est ce qui détermine le travail réellement réalisable.

Les calculs par cycle de 5 heures :

  • Z.ai Lite : 120 prompts × 18 appels = 2 160 appels du modèle
  • Z.ai Pro : 600 prompts × 18 appels = 10 800 appels du modèle
  • Claude Max 5x : 200 prompts = 200 appels du modèle
  • Claude Max 20x : 800 prompts = 800 appels du modèle

Si cette métrique “appels du modèle” est pertinente pour votre usage, Z.ai offre effectivement plus de capacité brute par cycle.

Comparaison globale

Plan Prix/mois Prompts max/mois Coût/1000 prompts Appels modèle/mois*
Z.ai Lite 3 $ ~34 560 0,09 $ ~622 000
Z.ai Pro 15 $ ~172 800 0,09 $ ~3 110 000
Claude Max 5x 100 $ ~57 600 1,74 $ ~57 600
Claude Max 20x 200 $ ~230 400 0,87 $ ~230 400

* Les “appels modèle” pour Z.ai supposent un facteur 18× selon leur documentation. Pour Claude, 1 prompt = 1 appel.

Analyse :

  • En volume brut de prompts, Claude Max 20x offre plus que Z.ai Lite (230 400 vs 34 560)
  • En coût par prompt, Z.ai est ~10-20× moins cher
  • Si le facteur multiplicateur Z.ai est réel, leur avantage en “travail effectif” est significatif

La vraie différence : les limites hebdomadaires

Claude Max impose des limites hebdomadaires documentées :

  • Max 5x : 140-280 heures de Sonnet 4 par semaine
  • Max 20x : 240-480 heures de Sonnet 4 par semaine

Ces limites sont généreuses pour la plupart des usages, mais peuvent être atteintes lors de sprints intensifs. Z.ai ne documente pas de telles limites hebdomadaires.

La qualité du modèle

C'est la question clé. Z.ai utilise GLM-4.7, Claude Max propose Sonnet et Opus.

En programmation, GLM-4.7 et Claude Sonnet 4.5 ont des performances similaires sur les benchmarks : 73,8 % pour GLM-4.7 sur SWE-bench Verified contre environ 77 % pour Sonnet 4.5. Cet écart reste marginal en pratique pour la plupart des tâches.

L'avantage de Claude Max reste l'accès à Opus, qui excelle sur les problèmes d'architecture complexe et le raisonnement avancé.


Intégration avec Claude Code : GLM CLI

L'avantage concret de Z.ai vient de son intégration avec Claude Code. Le projet xqsit94/glm offre un outil CLI simple qui élimine toute friction.

Installation

GLM CLI s'installe en une ligne :

curl -fsSL https://raw.githubusercontent.com/xqsit94/glm/main/install.sh | bash

Pas de configuration Docker, pas de variable d'environnement complexe, pas de fichiers de config à modifier.

Utilisation

Après installation et configuration du token Z.ai :

# Lancer Claude Code avec GLM-4.7 par défaut
glm

# Ou spécifier une version antérieure
glm --model glm-4.5-air

L'approche par session

GLM CLI utilise une approche temporaire : les paramètres du modèle ne s'appliquent que pour la session Claude Code lancée. Une fois fermée, Claude Code revient à son défaut.

  • Pas de pollution de la configuration globale
  • Sélection granulaire entre sessions
  • Pas de nettoyage nécessaire

Compatibilité

GLM-4.7 fonctionne avec Claude Code, Cline, Roo Code, Kilo Code, OpenCode et d'autres agents. Support des appels d'outils natifs.


Quand Claude Max reste pertinent

Z.ai ne surpasse pas Claude Max dans tous les cas :

  1. Accès à Opus. Pour les problèmes d'architecture complexe, les bugs subtils et le raisonnement avancé, Opus reste supérieur.

  2. Limites généreuses. Pour un usage modéré à intensif, les limites hebdomadaires de Claude Max (140-480 heures de Sonnet/semaine) sont rarement atteintes.

  3. Stabilité et support. Anthropic offre une infrastructure mature et un support établi.

  4. Qualité du modèle. Sonnet 4.5 reste légèrement supérieur à GLM-4.7 sur les benchmarks.

L'approche hybride

Pour maximiser le rapport qualité/prix :

  • Z.ai pour le travail quotidien (débogage, refactorisation, implémentation)
  • Claude Max 5x pour les problèmes complexes nécessitant Opus

Coût total mensuel : 103-115 $ selon le plan Z.ai choisi.

Cette approche donne :

  • Accès à GLM-4.7 pour la majorité des tâches à très faible coût
  • Accès à Opus pour les défis architecturaux
  • Plus de flexibilité qu'avec Max seul

Verdict

Profil Recommandation Coût
Travail occasionnel Z.ai Lite seul 3 $/mois
Travail régulier Z.ai Pro seul 15 $/mois
Travail intensif + besoin d'Opus Z.ai Pro + Claude Max 5x 115 $/mois
Budget disponible, simplicité Claude Max 20x seul 200 $/mois

Le contexte a changé. GLM-4.7 offre une alternative viable pour de nombreuses tâches de programmation. Mais contrairement à ce qui est parfois affirmé, Claude Max n'impose pas de limite stricte de sessions mensuelles — les deux services fonctionnent sur des cycles qui se réinitialisent.

La vraie question devient : avez-vous besoin d'Opus et de la qualité supérieure de Sonnet, ou le rapport qualité/prix de Z.ai suffit-il pour votre usage ?


Notes importantes

Les prix et limites correspondent à la situation de janvier 2026. Z.ai propose actuellement une promotion : réduction de 50 % le premier mois.

Les deux prestataires évoluent rapidement. Vérifiez toujours la documentation officielle pour les informations les plus récentes.


Sources

 
Read more...

from Ut0pia

“Claude Code c'est de l'héroïne pour programmeur.”

J'ai posté ça sur Mastodon début janvier 2026. Une formule volontairement provocante, mais qui résume assez bien mon année 2025. Une année où ma productivité a été multipliée par deux, peut-être par dix selon comment on compte.

Mais je me suis aussi demandé : est-ce que je ne serai pas en train de scier la branche sur laquelle je suis assis ?

Les fantômes des révolutions passées

Quand on parle d'IA et d'emploi, les comparaisons historiques fusent. “C'est comme l'arrivée de l'électricité !” “C'est comme Internet !” Soit. Mais si on gratte un peu, ces révolutions industrielles ont des leçons bien plus nuancées à nous offrir.

1811 : Les Luddites n'étaient pas des idiots

L'histoire officielle a fait des Luddites des technophobes arriérés, des casseurs de machines incapables de voir le progrès. C'est un mythe bien pratique.

En réalité, comme le rappelle le MIT Technology Review, les Luddites étaient des artisans qualifiés (tisserands, tricoteurs) qui voyaient très bien ce qui se passait. Ils n'étaient pas contre les machines. Ils étaient contre l'utilisation des machines pour dégrader leur travail et casser leurs salaires.

Leur leader, George Mellor, avait cette formule : “the tendency's all one way”, la tendance va dans un seul sens. Celui de la concentration des richesses au détriment des travailleurs.

Ça ne vous rappelle rien ?

40 ans de galère avant l'amélioration

Voici ce qu'on oublie souvent : pendant la première révolution industrielle en Angleterre, les salaires réels ont stagné pendant 40 ans alors que la productivité explosait. Quarante ans. Deux générations de travailleurs ont vu leur niveau de vie se dégrader pendant que les propriétaires d'usines s'enrichissaient.

Les choses se sont améliorées. Mais pas toutes seules. Il a fallu des grèves, des syndicats, des lois sociales arrachées de haute lutte. Le progrès technique n'a pas automatiquement ruisselé vers les travailleurs.

Ford et le paradoxe du salaire

Deuxième révolution industrielle, début du XXe siècle. Henry Ford installe ses chaînes de montage. Les ouvriers perdent toute autonomie : un geste, répété des centaines de fois par jour, sur un convoyeur qui impose le rythme.

Mais Ford fait quelque chose d'inattendu : il augmente les salaires. Pas par bonté d'âme mais pour fidéliser sa main-d'œuvre et surtout, transformer ses ouvriers en clients potentiels de ses voitures.

Le parallèle avec l'IA ? Les outils comme Claude Code ou Copilot sont accessibles aux développeurs individuels. Pour l'instant. La question est de savoir si cette démocratisation va durer, ou si on va vers une concentration où seules les grandes entreprises auront accès aux modèles les plus performants.

Les années 70 : la fin annoncée du travail de bureau

Troisième révolution, l'informatique. En 1970, l'invention du microprocesseur. Les ordinateurs personnels arrivent dans les bureaux. Les prédictions catastrophistes pleuvent : 47% des emplois américains seraient automatisables.

Résultat ? Le nombre d'emplois tertiaires a explosé. Les dactylos ont disparu, les développeurs sont apparus. Les comptables manuels ont laissé place aux experts-comptables assistés par logiciel.

La leçon : les métiers disparaissent rarement complètement. Ils se transforment.

2025 : Mon année avec les agents IA

Assez d'histoire. Parlons de ce qui m'est arrivé concrètement.

Le terminal est devenu mon assistant personnel

Depuis fin 2025, j'ai basculé. Mon IDE prend la poussière. Je passe mes journées dans un terminal avec Claude Code. Je décris ce que je veux, l'agent écrit le code, je supervise.

Le setup qui marche pour moi : – Un fichier claude.md avec des guidelines détaillées sur mon projet – Des skills personnalisés pour les tâches répétitives – Une codebase propre (l'IA travaille mieux sur du code bien structuré) – Docker Desktop pour les intégrations MCP

Coût : environ 1€ par heure de travail assisté, à mettre en parallèle avec la facturation d'un freelance qui tourne autour de 60€ par heure.

Ce que j'ai appris à mes dépens

L'IA est incompétente pour le debug. Vraiment. Elle peut écrire du code, refactorer, ajouter des fonctionnalités. Mais quand il s'agit de comprendre pourquoi ce foutu test échoue avec un message cryptique, elle tourne en rond. La supervision humaine reste indispensable sur les cas limites.

Les “Legacy Memories” sont un piège. Des années d'expérience m'ont appris des patterns, des réflexes. Certains sont devenus des boulets. L'IA ne fait pas les choses comme je les aurais faites et parfois, sa façon est meilleure. Désapprendre pour réapprendre, c'est le plus dur.

Un agent bien configuré, c'est zéro hallucination. J'ai commencé à ne plus relire certains outputs. Ça fait peur à écrire, mais c'est vrai. Avec Claude Code et Opus 4.5, sur une codebase propre avec des guidelines claires, les erreurs sont devenues rares.

L'analogie qui m'a convaincu

On ne relit pas l'assembleur généré par le compilateur. On fait confiance au compilateur. Personne ne vérifie ligne par ligne ce que GCC produit.

Sommes-nous en train de vivre la même transition avec le code généré par IA ?

Les mêmes peurs, vraiment ?

Révolution La peur Ce qui s'est passé
1ère (1780) Chômage de masse Nouveaux métiers, mais 40 ans de transition difficile
2ème (1870) Déshumanisation du travail Classe moyenne, société de consommation
3ème (1970) Fin du travail de bureau Explosion des emplois tertiaires
4ème (2025) Fin du développeur ? En cours...

Le World Economic Forum note que chaque révolution industrielle a créé plus d'emplois qu'elle n'en a détruits. Mais (et c'est un gros mais) les personnes qui perdent leur emploi ne sont pas forcément celles qui en trouvent un nouveau.

Les recherches historiques montrent que pendant la deuxième révolution industrielle, les jeunes travailleurs s'adaptaient en changeant de métier vers les secteurs en croissance. Les travailleurs plus âgés, eux, restaient coincés dans des emplois dévalorisés ou basculaient vers des postes non qualifiés.

Pattern inquiétant pour les développeurs de plus de 40 ans comme moi, surtout ceux que je vois refuser en bloc l'utilisation de ces outils.

La vraie question des Luddites

Comme le souligne TIME, la question n'a jamais été “la technologie va-t-elle nous remplacer ?” mais “qui contrôle la technologie et à qui profite-t-elle ?”

Aujourd'hui, les développeurs sont dans une position particulière. Nous sommes à la fois : – Les utilisateurs de ces outils (et nous en profitons) – Les créateurs de ces outils (certains d'entre nous) – Les potentielles victimes de ces outils (à terme ?)

Cette position ambiguë explique peut-être pourquoi le débat est si polarisé dans notre profession. Certains sont dans le déni (“l'IA ne pourra jamais faire ce que je fais”). D'autres dans l'euphorie aveugle (“plus besoin de développeurs dans 5 ans”). Les deux ont tort.

Ce qui me préoccupe (vraiment)

Je ne vais pas jouer les optimistes béats. Plusieurs choses m'inquiètent :

Le coût environnemental. Entraîner et faire tourner ces modèles consomme une énergie considérable. Mon gain de productivité a un coût carbone que je ne sais pas mesurer.

L'absence de régulation. On avance à toute vitesse sans cadre légal. Les révolutions industrielles précédentes ont fini par être encadrées: droit du travail, normes environnementales, régulation des monopoles. Pour l'IA, on n'en est nulle part.

La transition professionnelle. Je m'adapte parce que j'ai le luxe de pouvoir expérimenter. Qu'en est-il du développeur junior qui entre sur le marché ? Du senior qui a construit sa carrière sur une expertise que l'IA commoditise ?

Ni Luddite, ni techno-béat

Ma position, après quelques mois d'usage intensif : utiliser les outils sans naïveté.

J'utilise Claude Code tous les jours pour le pro bien sûr mais aussi pour le perso. Ma productivité a explosé et j'ai pu relancer moult projets persos qui stagnaient faute de temps.

Mais je ne suis pas dupe. Je milite pour une régulation de ces technologies. Je m'inquiète de leurs impacts environnementaux et sociaux. Je pense que la transition va faire des dégâts si elle n'est pas accompagnée.

Les Luddites avaient compris un truc essentiel : le progrès technique n'est pas neutre. Il peut servir à émanciper les travailleurs ou à les asservir. Ça dépend de choix politiques, pas de la technologie elle-même.

Et maintenant ?

Si vous êtes développeur, vous avez probablement déjà une opinion sur l'IA générative. Peut-être que vous l'utilisez quotidiennement. Peut-être que vous refusez d'y toucher. Peut-être que vous êtes quelque part entre les deux.

Mon conseil, pour ce qu'il vaut : expérimentez, mais gardez les yeux ouverts.

Apprenez à utiliser ces outils. Comprenez leurs limites. Maintenez vos compétences de supervision et d'architecture, ce que l'IA fait mal. Et surtout, participez au débat sur l'encadrement de ces technologies.

Les tisserands de 1811 ont perdu leur combat. Pas parce qu'ils avaient tort sur le fond, mais parce qu'ils n'avaient pas le rapport de force. Nous, développeurs de 2025, avons peut-être une fenêtre pour influencer la direction que prend cette révolution.

Ne la laissons pas passer.


Cet article s'appuie sur mes publications sur Mastodon et sur des recherches historiques. Les sources principales sont liées dans le texte.

Sources

 
Read more...

from Ut0pia

Vous avez une instance PeerTube et vous souhaitez y importer automatiquement certaines vidéos d'une chaîne YouTube ? Avec n8n, c'est possible en quelques clics.

Le principe

n8n est un outil d'automatisation open-source (comme Zapier, mais auto-hébergeable). L'idée est simple :

  1. Récupérer le flux RSS d'une chaîne YouTube
  2. Filtrer les vidéos selon nos critères
  3. Vérifier si la vidéo existe déjà sur PeerTube
  4. Si non, l'importer via l'API PeerTube

Prérequis

  • Une instance n8n (ex: n8n.example.org)
  • Une instance PeerTube (ex: video.example.org)
  • Les credentials OAuth2 de votre PeerTube

Étape 1 : Récupérer le flux RSS YouTube

Chaque chaîne YouTube dispose d'un flux RSS. L'URL est :

https://www.youtube.com/feeds/videos.xml?channel_id=CHANNEL_ID

Pour trouver le CHANNEL_ID, allez sur la chaîne YouTube et regardez l'URL. Par exemple pour la chaîne fictive “TechTalks” :

https://www.youtube.com/channel/UC1234567890abcdef

Dans n8n, créez un nœud HTTP Request : – Method: GET – URL: https://www.youtube.com/feeds/videos.xml?channel_id=UC1234567890abcdef – Response Format: Text

Étape 2 : Parser et filtrer les vidéos

Ajoutez un nœud Code pour extraire les vidéos qui nous intéressent. Par exemple, pour ne garder que les vidéos dont le titre contient “Tutorial” :

const xml = $input.first().json.data;
const entries = xml.split('<entry>');
const videos = [];

for (let i = 1; i < entries.length; i++) {
  const entry = entries[i];
  const videoIdMatch = entry.match(/<yt:videoId>([^<]+)<\/yt:videoId>/);
  const titleMatch = entry.match(/<title>([^<]+)<\/title>/);

  if (videoIdMatch && titleMatch) {
    const title = titleMatch[1];
    // Filtrer : ne garder que les tutoriels
    if (title.toLowerCase().includes('tutorial')) {
      videos.push({
        videoId: videoIdMatch[1],
        title: title,
        url: `https://www.youtube.com/watch?v=${videoIdMatch[1]}`
      });
    }
  }
}

if (videos.length > 0) {
  return [{json: videos[0]}];
}
return [];

Vous pouvez adapter le filtre selon vos besoins : – Mots-clés dans le titre – Exclusion de certains termes – Combinaison de critères

Étape 3 : Vérifier les doublons

Avant d'importer, vérifions que la vidéo n'existe pas déjà. Ajoutez un nœud HTTP Request :

  • Method: GET
  • URL: https://video.example.org/api/v1/search/videos?search={{ encodeURIComponent($json.title) }}&searchTarget=local

Puis un nœud Code pour filtrer :

const searchResult = $input.first().json;
const videoTitle = $('Parse RSS').first().json.title;
const videoUrl = $('Parse RSS').first().json.url;

const exists = searchResult.data?.some(v => v.name === videoTitle);

if (exists) {
  return []; // Vidéo déjà présente, on arrête
}

return [{json: {title: videoTitle, url: videoUrl}}];

Étape 4 : Obtenir un token PeerTube

Pour utiliser l'API PeerTube, il faut s'authentifier. Ajoutez un nœud HTTP Request :

  • Method: POST
  • URL: https://video.example.org/api/v1/users/token
  • Content-Type: application/x-www-form-urlencoded
  • Body:
    • client_id: votre client ID
    • client_secret: votre client secret
    • grant_type: password
    • username: votre username
    • password: votre password

Astuce : Vous pouvez trouver le client_id et client_secret via l'API /api/v1/oauth-clients/local.

Étape 5 : Importer la vidéo

Dernier nœud HTTP Request pour lancer l'import :

  • Method: POST
  • URL: https://video.example.org/api/v1/videos/imports
  • Headers: Authorization: Bearer {{ $json.access_token }}
  • Content-Type: multipart/form-data
  • Body:
    • targetUrl: l'URL YouTube
    • channelId: l'ID du channel PeerTube destination
    • privacy: 1 (public), 2 (unlisted), 3 (private)
    • name: le titre de la vidéo
    • category: l'ID de la catégorie (optionnel)

Planification

Ajoutez un nœud Schedule Trigger au début du workflow pour exécuter automatiquement l'import :

  • Toutes les 6 heures pour un flux actif
  • Une fois par jour pour un flux moins actif

Le workflow complet

[Schedule] → [Get RSS] → [Parse & Filter] → [Check Exists] → [Filter New] → [Get Token] → [Import]

Points d'attention

  1. Cookies YouTube : Si l'import échoue avec une erreur 403, PeerTube a peut-être besoin de cookies YouTube valides. Consultez la documentation yt-dlp pour configurer les cookies.

  2. Rate limiting : N'exécutez pas le workflow trop fréquemment pour éviter d'être bloqué par YouTube.

  3. Stockage : Les vidéos importées prennent de l'espace disque. Pensez à créer un workflow de nettoyage pour les anciennes vidéos si nécessaire.

  4. Légalité : Assurez-vous d'avoir le droit de republier les vidéos que vous importez (Creative Commons, accord de l'auteur, etc.).

Conclusion

n8n rend l'automatisation accessible à tous. Avec ce workflow, vous pouvez créer votre propre miroir PeerTube de contenus YouTube sélectionnés, tout en gardant le contrôle sur ce qui est importé grâce aux filtres.


Ressources utiles :Documentation n8nDocumentation PeerTubeAPI REST PeerTube

 
Read more...

from Ut0pia

Vous hébergez une instance PeerTube et vous souhaitez suivre vos statistiques de fréquentation sans compromettre la vie privée de vos visiteurs ? Plausible Analytics est la solution idéale.

Pourquoi Plausible ?

Plausible est une alternative open-source et respectueuse de la vie privée à Google Analytics. Contrairement à ce dernier :

  • Pas de cookies : aucune bannière RGPD nécessaire
  • Pas de données personnelles : les adresses IP sont hashées puis supprimées
  • Léger : le script fait moins de 1 Ko (vs ~45 Ko pour Google Analytics)
  • Open-source : vous pouvez l'auto-héberger

Notre infrastructure

Notre homelab utilise Docker Compose avec nginx-proxy pour le reverse proxy et Let's Encrypt pour les certificats SSL. La configuration complète est disponible sur GitHub.

Installation de Plausible

1. Configuration DNS

Ajoutez un enregistrement DNS pour votre sous-domaine analytics. Dans notre cas, nous utilisons plausible.votredomaine.org :

python3 scripts/ovh-dns.py add plausible --type A --ip VOTRE_IP
python3 scripts/ovh-dns.py add plausible --type AAAA --ip VOTRE_IPV6

2. Fichier Docker Compose

Créez le fichier services/plausible.yml :

services:
  plausible:
    image: ghcr.io/plausible/community-edition:v3.1.0
    container_name: plausible
    command: /entrypoint.sh run
    healthcheck:
      test: ["CMD-SHELL", "wget -q --spider http://127.0.0.1:8000/api/health || exit 1"]
      start_period: 2m
      interval: 30s
    environment:
      - BASE_URL=https://plausible.${DOMAIN}
      - SECRET_KEY_BASE=${PLAUSIBLE_SECRET_KEY}
      - TOTP_VAULT_KEY=${PLAUSIBLE_TOTP_KEY}
      - DISABLE_REGISTRATION=invite_only
      - DATABASE_URL=postgres://plausible:${PLAUSIBLE_DB_PASSWORD}@plausible-db:5432/plausible
      - CLICKHOUSE_DATABASE_URL=http://plausible-events-db:8123/plausible_events_db
      - VIRTUAL_HOST=plausible.${DOMAIN}
      - VIRTUAL_PORT=8000
      - LETSENCRYPT_HOST=plausible.${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - plausible-data:/var/lib/plausible
    networks:
      - proxy-tier
      - plausible-internal
    depends_on:
      plausible-db:
        condition: service_healthy
      plausible-events-db:
        condition: service_healthy

  plausible-db:
    image: postgres:16-alpine
    container_name: plausible-db
    environment:
      - POSTGRES_USER=plausible
      - POSTGRES_PASSWORD=${PLAUSIBLE_DB_PASSWORD}
      - POSTGRES_DB=plausible
    volumes:
      - /data/plausible-db:/var/lib/postgresql/data
    networks:
      - plausible-internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U plausible -d plausible"]
      start_period: 1m
      interval: 10s

  plausible-events-db:
    image: clickhouse/clickhouse-server:24.12-alpine
    container_name: plausible-events-db
    environment:
      - CLICKHOUSE_SKIP_USER_SETUP=1
    volumes:
      - /data/plausible-events-db:/var/lib/clickhouse
      - /data/plausible-clickhouse-config/listen.xml:/etc/clickhouse-server/config.d/listen.xml:ro
    networks:
      - plausible-internal
    healthcheck:
      test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider http://127.0.0.1:8123/ping || exit 1"]
      start_period: 1m
      interval: 10s

networks:
  proxy-tier:
    external: true
  plausible-internal:
    driver: bridge

volumes:
  plausible-data:

3. Configuration ClickHouse pour IPv4

ClickHouse écoute par défaut sur IPv6. Si votre réseau Docker n'a pas IPv6, créez ce fichier :

sudo mkdir -p /data/plausible-clickhouse-config
sudo tee /data/plausible-clickhouse-config/listen.xml << 'EOF'
<clickhouse>
    <listen_host>0.0.0.0</listen_host>
</clickhouse>
EOF

4. Variables d'environnement

Ajoutez ces variables à votre fichier .env :

PLAUSIBLE_SECRET_KEY=$(openssl rand -base64 48)
PLAUSIBLE_TOTP_KEY=$(openssl rand -base64 32)
PLAUSIBLE_DB_PASSWORD=$(openssl rand -base64 24)

5. Démarrage

docker compose -f docker-compose.yml -f services/plausible.yml up -d

Le premier démarrage peut prendre 1-2 minutes. Vérifiez que tout est healthy :

docker ps | grep plausible

6. Création du compte admin

Rendez-vous sur https://plausible.votredomaine.org et créez votre compte administrateur.

Intégration avec PeerTube

Ajouter le site dans Plausible

  1. Connectez-vous à votre instance Plausible
  2. Cliquez sur “Add a website”
  3. Entrez le domaine de votre PeerTube (ex: video.ut0pia.org)

Injecter le script dans PeerTube

Dans PeerTube, allez dans Administration → Configuration → Advanced → Custom JavaScript et ajoutez :

var script = document.createElement('script');
script.defer = true;
script.dataset.domain = 'video.votredomaine.org';
script.src = 'https://plausible.votredomaine.org/js/script.js';
document.head.appendChild(script);

Attention : Le champ “Custom JavaScript” attend du JavaScript pur, pas de balises HTML <script>.

Conformité RGPD

Plausible est conçu pour être conforme au RGPD sans bannière de consentement. Selon la politique de données de Plausible :

  • Aucun cookie n'est utilisé
  • Aucune donnée personnelle n'est collectée
  • Les adresses IP sont hashées et jamais stockées
  • Pas de tracking cross-site

Vous pouvez donc l'utiliser sans afficher de bannière cookie, tout en restant transparent dans votre politique de confidentialité.

Ressources

 
Read more...