Initial vault setup

concepts/a-b-testing.md

@@ -0,0 +1,37 @@
+---
+title: A/B Testing
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, devops, product]
+confidence: medium
+contested: false
+sources: []
+---
+# 🧪 A/B Testing
+
+## Définition Courte
+Méthode d'expérimentation où **deux variantes** (A et B) sont présentées à des sous-ensembles d'utilisateurs pour comparer leur performance sur une métrique donnée.
+
+## Explication Détaillée
+- On définit une **hypothèse** (ex: "un bouton rouge convertit mieux").
+- On répartit aléatoirement le trafic (50/50 ou autre split).
+- On collecte les métriques (conversion, rétention, etc.).
+- On utilise un **test statistique** (t-test, z-test) pour valider la significativité.
+- On décide de garder A ou B (ou de tester une variante C).
+
+## Cas d'Usage
+- Optimisation de landing pages.
+- Test de fonctionnalités produit.
+- Pricing.
+- Emails marketing.
+
+## Outils Liés
+- **Statsig**, **LaunchDarkly** (feature flag + A/B).
+- **PostHog Experiments**, **GrowthBook** (open-source).
+- **Google Optimize** (déprécié), **VWO**.
+
+## Pages Liées
+- [[feature-flags]]
+- [[boucle-feedback-client]]
+- [[pricing-strategy]]

concepts/api-gateway.md

@@ -0,0 +1,49 @@
+---
+title: API Gateway
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, architecture, networking]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🚪 API Gateway
+
+## Définition Courte
+Serveur unique servant de **point d'entrée** pour toutes les APIs d'un système, gérant l'auth, le routage, le rate limiting et l'observabilité de manière centralisée.
+
+## Explication Détaillée
+Sans API Gateway, chaque microservice expose ses propres endpoints et le client doit connaître toutes les URLs. Avec une gateway, le client parle à un seul point qui dispatche.
+
+Responsabilités typiques :
+- **Routage** : `/users/*` $\rightarrow$ service users, `/orders/*` $\rightarrow$ service orders.
+- **Auth** : vérification du token avant de router.
+- **Rate limiting** : protection contre les abus.
+- **Transformation** : convertir le format de requête (REST $\leftrightarrow$ gRPC).
+- **Observabilité** : tracer toutes les requêtes.
+
+## Cas d'Usage
+- Architecture microservices.
+- API publique avec plusieurs services backend.
+- Legacy modernization (façade devant un vieux SOAP).
+
+## Outils Liés
+- **Kong** (open-core, plugins).
+- **Traefik** (Docker-native).
+- **Envoy** (utilisé par Istio).
+- **AWS API Gateway**, **GCP API Gateway** (cloud).
+
+## Pages Liées
+- [[load-balancing]]
+- [[architecture-microservices]]
+- [[zero-trust]]
+- [[traefik]]
+
+## Questions Ouvertes
+- L'API Gateway est-il remplacé par les Service Mesh ?
+- Comment éviter que la gateway devienne un SPOF ?
+
+## Liens
+- [[rate-limiting]]
+- [[cache]]

concepts/api-rest.md

@@ -0,0 +1,40 @@
+---
+title: API REST
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, protocol, web]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📡 API REST
+
+## Définition Courte
+**REpresentational State Transfer** : style d'architecture pour les APIs web basé sur le protocole HTTP, les méthodes standard (GET, POST, PUT, DELETE) et des ressources identifiées par URL.
+
+## Explication Détaillée
+REST a été défini par Roy Fielding en 2000. Les principes clés :
+- **Stateless** : chaque requête contient toute l'info nécessaire (pas de session serveur).
+- **Ressources** identifiées par URI (`/users/42`).
+- **Représentations** : JSON, XML, etc. (le plus souvent JSON aujourd'hui).
+- **Méthodes HTTP sémantiques** : GET (lecture), POST (création), PUT/PATCH (modif), DELETE (suppression).
+- **HATEOAS** (optionnel) : liens hypermédia dans les réponses.
+
+## Cas d'Usage
+- APIs publiques (GitHub, Stripe, Twilio).
+- Communication frontend ↔ backend.
+- Microservices.
+
+## Outils Liés
+- **Frameworks** : Express, FastAPI, Gin, Spring.
+- **Documentation** : OpenAPI / Swagger.
+- **Tests** : Postman, Insomnia, HTTPie.
+
+## Pages Liées
+- [[concepts-web]]
+- [[graphql]]
+
+## Questions Ouvertes
+- REST vs GraphQL : quel trade-off pour quel projet ?
+- Comment versionner une API REST proprement ?

concepts/architecture-microservices.md

@@ -0,0 +1,52 @@
+---
+title: Architecture Microservices
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🧩 Architecture Microservices
+
+## Définition Courte
+Style d'architecture qui structure une application comme un ensemble de petits services autonomes, chacun exécutant un processus unique et communiquant via des API légères (souvent HTTP/REST ou gRPC).
+
+## Explication Détaillée
+Contrairement au **monolithe** où toute la logique métier est dans un seul codebase, les microservices découpent l'application en services indépendants par domaine métier (auth, paiement, catalogue, etc.). Chaque service :
+- Possède sa propre base de données (Database per Service).
+- Est déployable indépendamment.
+- Communique via des API ou une messagerie asynchrone (Kafka, RabbitMQ, NATS).
+- Tolère la panne d'autres services (degraded mode).
+
+**Avantages** : scalabilité indépendante de chaque service, isolation des pannes, équipes autonomes, polyglotisme technologique.
+**Inconvénients** : complexité opérationnelle accrue, latence réseau, transactions distribuées difficiles, debugging distribué.
+
+## Cas d'Usage
+- Applications à fort trafic avec des composants à scalabilités différentes (ex: Netflix, Amazon, Uber).
+- Équipes multiples travaillant en parallèle sur des domaines distincts.
+- Migration progressive d'un monolithe legacy.
+
+## Outils Liés
+- **Orchestration** : Kubernetes, Nomad, Docker Swarm.
+- **Service Mesh** : Istio, Linkerd.
+- **API Gateway** : Kong, Traefik, Envoy.
+- **Messagerie** : Kafka, RabbitMQ, NATS.
+- **Observabilité** : Prometheus, Jaeger, OpenTelemetry.
+
+## Pages Liées
+- [[patterns-architecture]]
+- [[docker]]
+- [[traefik]]
+
+## Questions Ouvertes
+- Comment gérer les transactions distribuées sans SAGA ?
+- Quel est le bon découpage en microservices (taille idéale) ?
+- Comment éviter le "distributed monolith" (microservices trop couplés) ?
+
+## Liens
+- [[message-queue]]
+- [[architecture-monolithique]]
+- [[comparatif-reverse-proxy]]
+- [[kubernetes]]

concepts/architecture-monolithique.md

@@ -0,0 +1,39 @@
+---
+title: Architecture Monolithique
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🗿 Architecture Monolithique
+
+## Définition Courte
+Style architectural où toute l'application est construite comme une seule unité déployable, avec une base de code partagée et un processus unique.
+
+## Explication Détaillée
+Dans un monolithe, toutes les fonctionnalités (UI, logique métier, accès données) sont compilées et déployées ensemble. Il peut être :
+- **Modulaire** : bien organisé en packages/modules logiques (monolithe "sain").
+- **Big Ball of Mud** : sans structure claire, fortement couplé (anti-pattern).
+
+**Avantages** : simplicité de développement au début, debugging facile (un seul processus), transactions ACID triviales, déploiement en un clic.
+**Inconvénients** : scalabilité linéaire (on duplique tout), déploiements risqués, dépendance forte entre équipes, choix technologique verrouillé.
+
+## Cas d'Usage
+- MVP et startups en phase de validation (time-to-market).
+- Petites équipes (< 10 devs).
+- Applications avec un domaine métier simple et stable.
+
+## Outils Liés
+- **Frameworks** : Django, Rails, Spring Boot, Laravel, NestJS.
+- **Base de données** : PostgreSQL, MySQL.
+
+## Pages Liées
+- [[patterns-architecture]]
+- [[architecture-microservices]]
+
+## Questions Ouvertes
+- Comment savoir quand il faut extraire un service du monolithe (signaux) ?
+- Un monolithe modulaire est-il un état final acceptable ou une étape transitoire ?

concepts/attaque-chaine-approvisionnement.md

@@ -0,0 +1,50 @@
+---
+title: Attaque de la Chaîne d'Approvisionnement
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, tech, devops]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ⛓️ Attaque de la Chaîne d'Approvisionnement (Supply Chain Attack)
+
+## Définition Courte
+Type de cyberattaque qui **cible les dépendances** d'un logiciel (bibliothèques, packages, outils de build) plutôt que directement la cible finale, compromettant des milliers d'applications en aval.
+
+## Explication Détaillée
+**Vecteurs d'attaque** :
+- **Compromission de package** : un attaquant publie une version malveillante d'une lib populaire (ex: event-stream sur npm, 2018).
+- **Dépendance transitive piégée** : vous importez une lib qui en importe 50 autres, dont une piégée.
+- **Compromission de maintainer** : compte GitHub piraté (XZ Utils backdoor, 2024).
+- **Build pipeline** : altération pendant la CI/CD (SolarWinds, 2020).
+- **Compromission de registry** : npm, PyPI piratés (rare mais catastrophique).
+
+**Pourquoi c'est dévastateur** : une seule compromission touche tous les projets qui utilisent la dépendance. L'effet domino est massif.
+
+## Cas d'Usage Réels
+- **Log4Shell (2021)** : Log4j, utilisé par des millions d'apps Java.
+- **XZ Utils (2024)** : backdoor dans sshd via la lib de compression.
+- **SolarWinds (2020)** : 18 000 clients compromis via une mise à jour signée.
+- **event-stream (2018)** : wallet Bitcoin volé via une lib npm.
+
+## Stratégies de Défense
+- **Pin des versions exactes** (jamais `^` ou `~`).
+- **Lock files** commités.
+- **SBOM** (Software Bill of Materials) : savoir exactement ce qu'on utilise.
+- **Signature de paquets** (Sigstore, GPG).
+- **Audit de dépendances** (npm audit, Snyk, Dependabot, Renovate).
+- **Sandbox des builds** (BuildKit, ephemeral CI).
+- **Provenance vérifiable** (SLSA framework).
+
+## Pages Liées
+- [[checklist-mise-en-production]]
+- [[securisation-home-lab]]
+- [[ci-cd]]
+- [[open-source]]
+- [[checklist-securite-vps]]
+
+## Questions Ouvertes
+- Peut-on vraiment se protéger à 100% sans auditer chaque dépendance à la main ?
+- Quel est l'avenir de la signature généralisée de paquets (Sigstore) ?

concepts/auto-hebergement.md

@@ -0,0 +1,22 @@
+---
+title: Auto-hébergement (Catégorie)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [auto-hébergement, meta]
+confidence: high
+contested: false
+sources: []
+---
+# 🏠 Auto-hébergement (Catégorie)
+
+L'**auto-hébergement** (self-hosting) désigne la pratique d'héberger soi-même ses services numériques sur sa propre infrastructure (serveur personnel, NAS, VPS).
+
+## Pages Liées
+- [[securisation-home-lab]] : sécuriser son serveur.
+- [[stack-ia-maison]] : faire tourner des IA localement.
+- [[strategie-backup-321]] : backups 3-2-1.
+- [[docker]], [[traefik]] : briques techniques.
+
+## Liens
+- [[nouveaux-projets-self-hosted]]

concepts/automatisation-dotfiles.md

@@ -0,0 +1,26 @@
+---
+title: Automatisation des Dotfiles
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, automation, open-source]
+sources: [raw/articles/dotfiles-automatisation.md]
+confidence: high
+contested: false
+---
+# 🌍 Automatisation des Dotfiles
+
+L'automatisation des **dotfiles** consiste à versionner et automatiser le déploiement des fichiers de configuration cachés (commençant par un point) d'un système Unix.
+
+## Outils de Gestion
+- **[[chezmoi]]** : Spécialisé dans la gestion des dotfiles avec support des templates.
+- **[[ansible]]** : Permet une configuration orchestrée et idempotente.
+
+## Bénéfices
+- **Reproductibilité** : Réinstallation complète d'un environnement de travail en quelques minutes.
+- **Versionnement** : Historique des changements de configuration via Git.
+
+## Liens
+- Outil : [[chezmoi]], [[ansible]]
+- Domaine : [[tech]]
+- [[dotfiles-automatisation]]

concepts/base-de-donnees-vectorielle.md

@@ -0,0 +1,44 @@
+---
+title: Base de Données Vectorielle
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, data, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🧊 Base de Données Vectorielle
+
+## Définition Courte
+Type de base de données optimisé pour stocker et rechercher des **vecteurs de grande dimension** (embeddings) en calculant la **similarité sémantique** plutôt que l'égalité exacte.
+
+## Explication Détaillée
+Les BDD classiques (SQL) sont excellentes pour des recherches exactes (`WHERE x = 5`), mais incapables de répondre à "trouve-moi les textes qui parlent de la même chose". Les bases vectorielles utilisent des algorithmes d'**ANN (Approximate Nearest Neighbors)** comme HNSW, IVF ou ScaNN pour trouver les k plus proches voisins d'un vecteur en quelques millisecondes, même sur des millions de points.
+
+Métriques de distance :
+- **Cosine** : angle entre vecteurs (le plus courant pour le texte).
+- **Euclidean (L2)** : distance géométrique.
+- **Dot Product** : produit scalaire.
+
+## Cas d'Usage
+- **RAG** : retrouver les passages pertinents pour un LLM (cf. [[rag]]).
+- Recherche sémantique (moteur de recherche par le sens).
+- Recommandation (produits similaires).
+- Détection d'anomalies.
+- Déduplication de documents.
+
+## Outils Liés
+- **Open-source** : Qdrant, Milvus, Weaviate, ChromaDB.
+- **Postgres** : extension pgvector.
+- **SaaS** : Pinecone.
+- **Algorithmes** : FAISS (Meta), Annoy (Spotify), ScaNN (Google).
+
+## Pages Liées
+- [[rag]], [[embeddings]]
+- [[comparatif-stockage]]
+- [[hebergement-llm-solo-dev]]
+
+## Questions Ouvertes
+- À partir de quelle taille de corpus faut-il une vraie base vectorielle (vs SQLite) ?
+- L'arrivée des modèles à 1M+ tokens de contexte rend-elle les bases vectorielles moins utiles ?

concepts/boucle-feedback-client.md

@@ -0,0 +1,56 @@
+---
+title: Boucle de Feedback Client
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [business, product, strategy]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔁 Boucle de Feedback Client (Customer Feedback Loop)
+
+## Définition Courte
+Processus **cyclique** qui consiste à : **collecter** les retours des utilisateurs $\rightarrow$ **analyser** $\rightarrow$ **prioriser** $\rightarrow$ **implémenter** $\rightarrow$ **communiquer** les changements $\rightarrow$ mesurer l'impact, puis recommencer.
+
+## Explication Détaillée
+**Sources de feedback** :
+- **Direct** : interviews, surveys, NPS, support tickets, sales calls.
+- **Indirect** : analytics, heatmaps, enregistrements de session, churn analysis.
+- **Public** : reviews, Reddit, Twitter/X, GitHub issues.
+
+**Outils** :
+- Intercom / Crisp / Front (support + insights).
+- Hotjar / Microsoft Clarity (heatmaps).
+- Posthog / Amplitude (product analytics).
+- Canny / Featurebase (feature requests).
+
+**Cadres d'analyse** :
+- **RICE** : Reach, Impact, Confidence, Effort.
+- **ICE** : Impact, Confidence, Ease.
+- **Jobs to Be Done** : qu'est-ce que l'utilisateur veut accomplir.
+
+**Anti-patterns** :
+- **HiPPO** (Highest Paid Person's Opinion) : la voix du boss > les users.
+- **Feedback sélectif** : n'écouter que les "forts".
+- **Pas de fermeture de boucle** : implémenter sans jamais dire "on vous a écouté".
+
+## Cas d'Usage
+- Roadmap produit d'un SaaS.
+- Amélioration continue d'une feature.
+- Détection des points de friction.
+- Validation d'une nouvelle idée avant build.
+
+## Outils Liés
+- **Canny**, **Featurebase** (feature requests).
+- **Hotjar**, **PostHog** (analytics).
+- **Linear**, **Notion** (roadmap).
+
+## Pages Liées
+- [[pricing-strategy]]
+- [[nouveautes-ia-par-mois]]
+- [[monetisation-open-source]]
+
+## Questions Ouvertes
+- Comment prioriser entre les demandes des power users et celles des novices ?
+- Le feedback client peut-il nous faire perdre notre vision produit (feature factory) ?

concepts/bsl.md

@@ -0,0 +1,38 @@
+---
+title: BSL (Business Source License)
+created: 2026-06-06
+updated: 2026-06-06
+type: entity
+tags: [open-source, legal]
+confidence: medium
+contested: false
+sources: []
+---
+# 📜 BSL (Business Source License)
+
+## Définition Courte
+Licence **source-available** (et non open-source selon l'OSI) développée par MariaDB : le code est visible, mais限制 commercial (notamment le cloud) pendant quelques années, après quoi il bascule en open-source.
+
+## Explication Détaillée
+- Créée en 2013 par MariaDB pour protéger son activité contre AWS.
+- Utilisée par HashiCorp (Terraform), Sentry, CockroachDB.
+- Délai de grâce typique : 4 ans, puis conversion en Apache 2.0.
+- Souvent perçue comme une "AGPL douce" : pas copyleft, mais限制 commerciale.
+
+## Cas d'Usage
+- Éditeurs de BDD (CockroachDB, MariaDB).
+- Outils dev (Terraform, Sentry).
+- Projets voulant financer le dev sans perdre le contrôle.
+
+## Outils Liés
+- [[apache-2]] (destination typique après délai).
+- [[gpl-v3]] (alternative copyleft).
+- [[sspl]] (variante copyleft stricte).
+
+## Pages Liées
+- [[licences-open-source]]
+- [[monetisation-open-source]]
+- [[open-source]]
+
+## Liens
+- [[veille-licences]]

concepts/cache.md

@@ -0,0 +1,54 @@
+---
+title: Cache
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, architecture, performance]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ⚡ Cache
+
+## Définition Courte
+Stockage **temporaire** de données coûteuses à recalculer ou à récupérer, pour servir les requêtes suivantes **beaucoup plus vite**.
+
+## Explication Détaillée
+**Couches de cache** (de la plus proche au plus loin) :
+1. **CPU Cache** (L1, L2, L3) : nanosecondes.
+2. **RAM Cache** (Redis, Memcached) : microsecondes.
+3. **Disk Cache** (SSD) : millisecondes.
+4. **CDN Edge** (Cloudflare, Fastly) : dizaine de ms.
+5. **HTTP Cache** (browser) : réutilisé localement.
+
+**Patterns** :
+- **Cache-Aside** : l'app lit le cache, sinon lit la source et remplit.
+- **Read-Through** : le cache est transparent, lit la source si besoin.
+- **Write-Through** : l'écriture passe par le cache puis la source.
+- **Write-Behind** : écriture async (risque de perte).
+- **Cache Stampede Prevention** : éviter que 1000 requêtes régénèrent la même clé en parallèle.
+
+**Invalidation** : le plus dur en cache. TTL, événement-based, ou manuelle.
+
+## Cas d'Usage
+- Sessions utilisateurs (Redis).
+- Réponses API coûteuses (résultats LLM, RAG).
+- Assets statiques (images, JS via CDN).
+- Requêtes DB lourdes.
+- Résultats de pagination.
+
+## Outils Liés
+- **Redis**, **Memcached**, **KeyDB** (in-memory).
+- **Varnish**, **NGINX** (HTTP cache).
+- **Cloudflare**, **Fastly** (CDN).
+- **Stale-While-Revalidate** (SWR).
+
+## Pages Liées
+- [[load-balancing]]
+- [[api-gateway]]
+- [[comparatif-stockage]]
+- [[observabilite]]
+
+## Questions Ouvertes
+- Le cache L1/L2 de CPU est-il encore pertinent à optimiser en 2025 ?
+- Comment gérer le cache distribué sans point unique de défaillance ?

concepts/canary-deployment.md

@@ -0,0 +1,20 @@
+---
+title: Déploiement Canary Avancé
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [devops, tech, architecture]
+confidence: medium
+contested: false
+sources: []
+---
+# 💻 Déploiement Canary Avancé
+
+Variante avancée du canary deployment : déploiement progressif à un % d'utilisateurs avec analyse statistique automatique.
+
+Voir [[deploiement-canary]] pour la page principale.
+
+## Pages Liées
+- [[deploiement-canary]]
+- [[deploiement-blue-green]]
+- [[feature-flags]]

concepts/chain-of-thought.md

@@ -0,0 +1,25 @@
+---
+title: Chain-of-Thought (CoT)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [AI, architecture]
+sources: [raw/articles/prompt-engineering-agents.md]
+confidence: high
+contested: false
+---
+# 🪜 Chain-of-Thought (CoT)
+
+La **Chaîne de Pensée** (CoT) est une technique qui consiste à forcer le modèle à générer des étapes de raisonnement intermédiaires avant d'arriver à la réponse finale.
+
+## Pourquoi ça marche ?
+En écrivant son raisonnement, le modèle utilise ses propres tokens de sortie comme "mémoire de travail" supplémentaire, ce qui lui permet de traiter des problèmes logiques ou mathématiques plus complexes sans sauter d'étapes.
+
+## Méthodes d'activation
+- **Zero-shot CoT** : Ajouter la phrase "Réfléchissons étape par étape" au prompt.
+- **Few-shot CoT** : Fournir des exemples où la réponse est précédée d'un raisonnement détaillé.
+
+## Liens
+- Cadre général : [[prompt-engineering-agents]]
+- [[transformer-architecture]]
+- [[function-calling]]

concepts/chaos-engineering.md

@@ -0,0 +1,48 @@
+---
+title: Chaos Engineering
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [devops, tech, resilience]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 💥 Chaos Engineering
+
+## Définition Courte
+Discipline consistant à **injecter volontairement des pannes** dans un système pour observer sa résilience et identifier les faiblesses avant qu'elles ne surviennent en production.
+
+## Explication Détaillée
+Popularisé par Netflix (via les Chaos Monkey), le Chaos Engineering suit ces étapes :
+1. Définir un "steady state" (état normal mesurable).
+2. Émettre une hypothèse (ex: "si la DB tombe, le service reste dégradé").
+3. Injecter un défaut (kill d'instance, latence, erreur réseau).
+4. Observer l'écart au steady state.
+5. Apprendre et améliorer.
+
+**Avantages** : résilience mesurée, culture de la fiabilité, découverte de bugs cachés.
+**Inconvénients** : demande de la maturité, peut être coûteux à mettre en place.
+
+## Cas d'Usage
+- Microservices à fort trafic.
+- Validation de stratégies de fallback.
+- Tests de disaster recovery.
+
+## Outils Liés
+- **Chaos Monkey** (Netflix).
+- **Gremlin** (commercial, complet).
+- **Litmus** (Kubernetes-native).
+- **ChaosBlade** (Alibaba).
+
+## Pages Liées
+- [[observabilite]]
+- [[architecture-microservices]]
+- [[ci-cd]]
+
+## Questions Ouvertes
+- Le chaos engineering est-il rentable pour une PME ?
+- Comment convaincre la direction de "casser la prod volontairement" ?
+
+## Liens
+- [[load-shedding]]

concepts/checklist-mise-en-production.md

@@ -0,0 +1,54 @@
+---
+title: Checklist Mise en Production
+created: 2026-06-06
+updated: 2026-06-06
+type: recipe
+tags: [devops, automation, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ✅ Checklist de Mise en Production
+
+Étapes à valider avant de passer un service du mode "développement" au mode "production".
+
+## 🔧 Configuration
+- [ ] Les variables sensibles sont externalisées (fichier `.env`, Vault, secrets Docker).
+- [ ] Les mots de passe par défaut ont été changés.
+- [ ] Le service tourne sous un utilisateur non-root (cf. [[docker]] - User Namespaces).
+- [ ] Les ports de debug sont désactivés (ex: ports DevTools, ports de debug distants).
+
+## 🔐 Sécurité Réseau
+- [ ] Le service est derrière un [[traefik]] (reverse proxy) et n'est pas exposé directement sur internet.
+- [ ] Le SSL/TLS est actif (cf. [[tls-https]]).
+- [ ] Les headers de sécurité HTTP sont configurés (HSTS, X-Frame-Options, CSP).
+- [ ] Fail2ban / CrowdSec est actif (cf. [[securisation-home-lab]]).
+
+## 💾 Données et Persistance
+- [ ] Les volumes sont persistants et sauvegardés (cf. [[strategie-backup-321]]).
+- [ ] Une restauration à blanc a été testée au moins une fois.
+- [ ] La base de données a un script d'init/migrations documenté.
+
+## 📊 Observabilité
+- [ ] Les logs sont centralisés (cf. [[checklist-monitoring-minimal]]).
+- [ ] Les métriques de base (CPU, RAM, disque) sont surveillées.
+- [ ] Une alerte est en place en cas de panne (Uptime Kuma, Healthchecks.io).
+
+## ⚡ Performance
+- [ ] La consommation RAM/CPU a été mesurée en charge.
+- [ ] Le cache est configuré (ex: Redis, page cache).
+- [ ] Le service redémarre automatiquement en cas de crash (`restart: unless-stopped`).
+
+## 🔄 CI/CD
+- [ ] Les images Docker utilisées sont pinnées (version exacte, pas de `latest` en prod).
+- [ ] Un système de mise à jour est en place (Watchtower, Diun, ou manuel).
+- [ ] Un rollback est possible rapidement (image tag précédente conservée).
+
+## Liens
+- [[checklist-securite-vps]], [[checklist-monitoring-minimal]]
+- [[securisation-home-lab]]
+- [[rate-limiting]]
+- [[deploiement-blue-green]]
+- [[attaque-chaine-approvisionnement]]
+- [[deploiement-solo-dev]]
+- [[monitoring-solo-dev]]

concepts/checklist-monitoring-minimal.md

@@ -0,0 +1,43 @@
+---
+title: Checklist Monitoring
+created: 2026-06-06
+updated: 2026-06-06
+type: recipe
+tags: [monitoring, devops, auto-hébergement]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ✅ Checklist Monitoring Minimal
+
+Surveiller l'état de santé d'un serveur ou d'un service sans se ruiner.
+
+## 📊 Métriques Système (de base)
+- [ ] CPU, RAM, Disque, Load Average surveillés (via Netdata, Glances, ou Prometheus + node-exporter).
+- [ ] Alerte si le disque est > 80% plein.
+- [ ] Alerte si la RAM est saturée de manière répétée.
+
+## 🌐 Surveillance des Services
+- [ ] Uptime Kuma ou équivalent pour checker HTTP/TCP des services.
+- [ ] Notifications configurées (Telegram, Discord, Email, Gotify).
+- [ ] Intervalle de check adapté (60s pour le web, 5min pour les batchs).
+
+## 📜 Centralisation des Logs
+- [ ] Les logs Docker sont collectés (Loki + Grafana, ou Dozzle pour du simple).
+- [ ] Rétention des logs définie (ex: 30 jours).
+- [ ] Pas de logs sensibles (mots de passe, tokens) en clair.
+
+## 🔔 Alertes Intelligentes
+- [ ] Distinguer les alertes critiques (service down) des warnings (disque 80%).
+- [ ] Un canal "silencieux" pour les infos, un canal bruyant pour les urgences.
+- [ ] Un "dead man switch" : alerte si le monitoring lui-même s'arrête (Healthchecks.io).
+
+## 🛠️ Dashboards
+- [ ] Un dashboard global (Grafana) est accessible depuis l'extérieur (Tailscale, VPN).
+- [ ] Les dashboards documentés (les noms des métriques sont explicites).
+
+## Liens
+- Outils suggérés : Uptime Kuma, Netdata, Grafana, Loki, Dozzle.
+- [[checklist-mise-en-production]]
+- [[checklist-securite-vps]]
+- [[monitoring-solo-dev]]

concepts/checklist-sauvegardes-restauration.md

@@ -0,0 +1,44 @@
+---
+title: Checklist Sauvegardes
+created: 2026-06-06
+updated: 2026-06-06
+type: recipe
+tags: [backup, auto-hébergement, security]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ✅ Checklist Sauvegardes et Restauration
+
+Garantir la récupérabilité de vos données en cas de sinistre.
+
+## ✅ Les Bases (3-2-1)
+- [ ] 3 copies de chaque donnée critique.
+- [ ] 2 supports différents (ex: SSD interne + NAS).
+- [ ] 1 copie hors site (cf. [[strategie-backup-321]]).
+
+## ⚙️ Configuration
+- [ ] Sauvegarde **chiffrée** côté client (cf. [[restic]]).
+- [ ] Compression activée pour économiser l'espace de stockage.
+- [ ] Politique de rétention définie (ex: garder 7 quotidiennes, 4 hebdomadaires, 12 mensuelles).
+- [ ] Les sauvegardes incluent : volumes Docker, bases de données, fichiers de configuration (`/etc`), et dotfiles.
+
+## 🤖 Automatisation
+- [ ] Tâches planifiées (cron) fonctionnelles et vérifiées.
+- [ ] Notifications activées en cas d'échec de la sauvegarde.
+- [ ] Pas de credentials en clair dans les crontabs (utiliser des variables d'environnement ou un secret manager).
+
+## 🧪 Tests de Restauration
+- [ ] Un test de restauration **à blanc** est effectué au moins trimestriellement.
+- [ ] Le temps de restauration (RTO) est documenté et connu.
+- [ ] La procédure est écrite et accessible même depuis un autre poste.
+
+## 📦 Hors Site
+- [ ] Cloud choisi (Backblaze B2, AWS S3, etc.) - maîtriser les coûts de stockage et d'egress.
+- [ ] Bande passante suffisante pour l'upload initial si volumineux.
+- [ ] Clés d'accès API stockées de manière sécurisée.
+
+## Liens
+- Outil : [[restic]]
+- Concept : [[strategie-backup-321]]
+- [[checklist-monitoring-minimal]]

concepts/checklist-securite-vps.md

@@ -0,0 +1,49 @@
+---
+title: Checklist Sécurité VPS
+created: 2026-06-06
+updated: 2026-06-06
+type: recipe
+tags: [security, auto-hébergement, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ✅ Checklist Sécurité VPS
+
+Sécurisation d'un serveur exposé sur internet (VPS, serveur dédié, ou machine auto-hébergée avec port forwarding).
+
+## 🚫 Accès SSH
+- [ ] Désactiver la connexion root (`PermitRootLogin no` dans `/etc/ssh/sshd_config`).
+- [ ] Utiliser uniquement des clés SSH (désactiver `PasswordAuthentication yes`).
+- [ ] Changer le port SSH par défaut (22) pour réduire le bruit des bots.
+- [ ] Activer [[openssh]] en mode post-quantique si possible.
+- [ ] Limiter les utilisateurs pouvant se connecter (`AllowGroups ssh-users`).
+
+## 🛡️ Pare-feu
+- [ ] Politique par défaut : tout bloquer (`ufw default deny incoming` ou `nftables`).
+- [ ] N'ouvrir QUE les ports strictement nécessaires (80, 443, et SSH personnalisé).
+- [ ] Activer le rate limiting sur les services web (via [[traefik]]).
+
+## 🔄 Mises à jour
+- [ ] Activer les mises à jour de sécurité automatiques (`unattended-upgrades` sur Debian/Ubuntu).
+- [ ] Auditer régulièrement les paquets installés (pas de logiciels inutiles).
+- [ ] Surveiller les CVE sur les images Docker utilisées.
+
+## 👁️ Détection
+- [ ] Installer [[fail2ban]] ou [[crowdsec]].
+- [ ] Configurer des alertes sur les nouveaux comptes administrateurs.
+- [ ] Surveiller les logs d'authentification (`/var/log/auth.log`).
+
+## 💾 Post-Incident
+- [ ] Disposer d'un snapshot/image système de référence (à jour).
+- [ ] Connaître la procédure de réinitialisation des clés SSH perdues via la console provider.
+- [ ] Avoir un canal de communication de secours (email) en cas de perte d'accès SSH.
+
+## Liens
+- [[checklist-sauvegardes-restauration]]
+- [[checklist-monitoring-minimal]]
+- [[openssh]], [[fail2ban]], [[crowdsec]]
+- [[firewall]]
+- [[cles-ssh]]
+- [[rotation-secrets]]
+- [[attaque-chaine-approvisionnement]]

concepts/chiffrement-bout-en-bout.md

@@ -0,0 +1,47 @@
+---
+title: Chiffrement de Bout en Bout (E2EE)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, crypto, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔐 Chiffrement de Bout en Bout (E2EE)
+
+## Définition Courte
+Méthode de chiffrement où **seuls les participants** d'une communication peuvent lire les messages. Le serveur relais ne voit que des données chiffrées.
+
+## Explication Détaillée
+Contrairement au TLS classique (qui protège en transit mais où le serveur voit en clair), l'E2EE garantit que le fournisseur de service (ex: Signal) ne peut techniquement pas lire vos messages, même s'il le voulait (ou s'il est saisi par la police).
+
+Protocoles :
+- **Signal Protocol** : référence, utilisé par Signal, WhatsApp.
+- **MLS** (Messaging Layer Security) : nouveau standard IETF.
+- **PGP / GPG** : ancien, pour email.
+- **OMEMO** (XMPP) : pour Matrix.
+
+## Cas d'Usage
+- Messagerie privée (Signal, WhatsApp).
+- Email sensible (ProtonMail, Tutanota).
+- Stockage chiffré (Cryptomator, Tresorit).
+- VPN/WireGuard (chiffrement du tunnel).
+
+## Outils Liés
+- **Signal**, **Matrix** (E2EE).
+- **ProtonMail**.
+- **Age** (chiffrement de fichiers moderne, successeur de GPG).
+- **Cryptomator** (chiffrement de dossiers cloud).
+
+## Pages Liées
+- [[tls-https]]
+- [[vpn]]
+- [[cryptographie-post-quantique]]
+
+## Questions Ouvertes
+- E2EE est-il menacé par les futures régulations (backdoor obligatoire) ?
+- Comment concilier E2EE et fonctionnalités IA (analyse, recherche) ?
+
+## Liens
+- [[hash-cryptographique]]

concepts/ci-cd.md

@@ -0,0 +1,47 @@
+---
+title: CI/CD
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [devops, automation, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔁 CI/CD
+
+## Définition Courte
+**Continuous Integration / Continuous Deployment** : ensemble de pratiques automatisant les étapes entre l'écriture de code et sa mise en production.
+
+## Explication Détaillée
+- **CI (Intégration Continue)** : à chaque push, le code est compilé, testé, linté. Détecte les régressions tôt.
+- **CD (Livraison/Déploiement Continu)** : après CI, le code est déployé automatiquement (ou avec un bouton) en staging puis en prod.
+
+**Avantages** : déploiements fréquents et moins risqués, feedback rapide, moins de "ça marche sur ma machine".
+**Inconvénients** : complexité de la pipeline, tests à maintenir, surface d'attaque accrue (secrets, artefacts).
+
+## Cas d'Usage
+- Toute équipe > 2 devs.
+- Projets open-source (CI gratuite via GitHub Actions, GitLab CI).
+- Livraison rapide de features.
+
+## Outils Liés
+- **GitHub Actions**, **GitLab CI**, **CircleCI**.
+- **Jenkins** (auto-hébergeable, très flexible).
+- **ArgoCD**, **Flux** (GitOps pour Kubernetes).
+- **Woodpecker** (CI open-source légère, alternative à Drone).
+
+## Pages Liées
+- [[infrastructure-as-code]]
+- [[checklist-mise-en-production]]
+- [[docker]]
+
+## Questions Ouvertes
+- GitOps est-il l'avenir du CD ?
+- Comment sécuriser une pipeline CI/CD (supply chain attacks) ?
+
+## Liens
+- [[deploiement-blue-green]]
+- [[deploiement-canary]]
+- [[feature-flags]]
+- [[breaking-changes-ecosysteme]]

concepts/circuit-breaker.md

@@ -0,0 +1,39 @@
+---
+title: Circuit Breaker
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [architecture, tech, devops]
+confidence: medium
+contested: false
+sources: []
+---
+# ⚡ Circuit Breaker
+
+## Définition Courte
+Pattern de **résilience** qui interrompt les appels vers un service en panne pour éviter la cascade d'échecs, en ouvrant un "circuit" (court-circuit) pendant un délai, puis en testant la récupération.
+
+## Explication Détaillée
+**3 états** :
+- **Closed** (fermé) : appels normaux, monitoring des échecs.
+- **Open** (ouvert) : tous les appels échouent immédiatement, on laisse le service récupérer.
+- **Half-Open** (semi-ouvert) : on laisse passer quelques requêtes tests pour voir si le service est rétabli.
+
+**Pourquoi ?** Sans circuit breaker, un service en panne fait s'empiler des requêtes, épuiser les threads, et crasher le service appelant (effet domino).
+
+## Cas d'Usage
+- Appels à des API externes peu fiables.
+- Communication entre microservices.
+- Protection des appels coûteux (LLM, base de données).
+
+## Outils Liés
+- **Hystrix** (Netflix, historique, plus maintenu).
+- **Resilience4j** (Java moderne).
+- **Polly** (.NET).
+- **Istio** (service mesh avec circuit breaker intégré).
+
+## Pages Liées
+- [[load-shedding]]
+- [[haute-disponibilite]]
+- [[message-queue]]
+- [[architecture-microservices]]

concepts/cles-ssh.md

@@ -0,0 +1,53 @@
+---
+title: Clés SSH
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, tech, dev]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔑 Clés SSH
+
+## Définition Courte
+Paire de clés cryptographiques (une privée gardée secrète, une publique partagée) utilisée pour l'authentification forte à un serveur SSH, en remplacement des mots de passe.
+
+## Explication Détaillée
+Algorithmes recommandés en 2024+ :
+- **Ed25519** : moderne, rapide, signatures courtes. **Recommandé par défaut**.
+- **ECDSA** (NIST P-256) : alternative, bien supportée.
+- **RSA 4096 bits** : toujours sûr, mais plus lent.
+- **DSA** : **cassé**, à ne plus utiliser.
+
+Workflow :
+1. Génération : `ssh-keygen -t ed25519 -C "commentaire"`.
+2. Déploiement : `ssh-copy-id user@serveur` (ou via `~/.ssh/authorized_keys`).
+3. Connexion : le serveur challenge avec un truc que seule la clé privée peut signer.
+
+Concepts avancés :
+- **passphrase** : protection supplémentaire de la clé privée.
+- **ssh-agent** : déverrouille la clé en mémoire pour la session.
+- **agent forwarding** : permet de rebondir via plusieurs serveurs.
+- **AuthorizedKeysCommand** : gestion centralisée (LDAP, Vault).
+
+## Cas d'Usage
+- Accès SSH à un VPS.
+- Authentification Git (GitHub, GitLab).
+- Déploiement CI/CD (clés de déploiement).
+- Backup automatisé (rsync via SSH).
+
+## Outils Liés
+- **OpenSSH** (cf. [[openssh]]).
+- **1Password / Bitwarden** : gestion moderne des clés.
+- **HashiCorp Vault SSH** : rotation automatique.
+
+## Pages Liées
+- [[openssh]]
+- [[checklist-securite-vps]]
+- [[secret-management]]
+- [[zero-trust]]
+
+## Questions Ouvertes
+- Faut-il adopter massivement les passkeys au détriment des clés SSH ?
+- Comment gérer les clés SSH dans une équipe de 10+ devs sans Vault ?

concepts/concepts-web.md

@@ -0,0 +1,40 @@
+---
+title: Concepts Web
+created: 2026-06-06
+updated: 2026-06-06
+type: glossary
+tags: [web, tech, protocol]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📖 Concepts Essentiels du Web Moderne
+
+Glossaire des technologies et architectures qui sous-tendent internet aujourd'hui.
+
+- **HTTP / HTTPS** : Protocole de transfert hypertexte. HTTPS est la version chiffrée via [[tls-https]].
+- **DNS (Domain Name System)** : "Annuaire" qui traduit les noms de domaine en adresses IP.
+- **IP (Internet Protocol)** : Adresse unique assignée à chaque appareil sur un réseau (IPv4: 32 bits, IPv6: 128 bits).
+- **TCP / UDP** : Protocoles de transport. TCP est fiable et ordonné, UDP est rapide mais sans garantie.
+- **REST API** : Style d'architecture d'API basé sur le protocole HTTP et ses méthodes (GET, POST, PUT, DELETE).
+- **GraphQL** : Langage de requête pour API permettant au client de demander exactement les données dont il a besoin.
+- **WebSocket** : Protocole de communication bidirectionnelle en temps réel sur une connexion TCP.
+- **CORS (Cross-Origin Resource Sharing)** : Mécanisme de sécurité autorisant ou bloquant les requêtes entre domaines différents.
+- **JWT (JSON Web Token)** : Standard de token sécurisé pour l'authentification.
+- **OAuth 2.0 / OIDC** : Protocoles d'authentification déléguée (ex: "Se connecter avec Google"). OIDC est la couche d'identité par-dessus OAuth2.
+- **Cookie** : Petit fichier stocké dans le navigateur pour mémoriser une session.
+- **CDN (Content Delivery Network)** : Réseau de serveurs distribués pour servir du contenu statique au plus près de l'utilisateur.
+- **WebAssembly (WASM)** : Format binaire exécutable dans les navigateurs, presque aussi rapide que du natif.
+- **JAMstack** : Architecture web basée sur JavaScript, APIs et Markup (sites statiques pré-rendus).
+- **SSR (Server-Side Rendering)** : Rendu de la page HTML côté serveur (ex: Next.js, Nuxt).
+- **SPA (Single Page Application)** : Application web qui charge une seule page HTML et met à jour le contenu dynamiquement (ex: React, Vue).
+- **Serverless** : Modèle où le cloud gère l'infrastructure (ex: AWS Lambda, Vercel Functions).
+- **Webhooks** : Mécanisme de rappel HTTP : un service notifie un autre service via une URL en cas d'événement.
+- **Idempotence** : Propriété d'une opération qui produit le même résultat qu'on l'exécute une ou plusieurs fois.
+- **Rate Limiting** : Limitation du nombre de requêtes qu'un client peut faire sur une période donnée.
+
+## Liens
+- Protocole : [[tls-https]]
+- Domaine : [[tech]]
+- [[rate-limiting]]
+- [[webassembly]]

concepts/concepts.md

@@ -0,0 +1,3 @@
+---
+sticker: emoji//1f953
+---

concepts/conteneurisation.md

@@ -0,0 +1,47 @@
+---
+title: Conteneurisation
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, docker, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📦 Conteneurisation
+
+## Définition Courte
+Technique d'isolation légère qui exécute une application et ses dépendances dans un **environnement utilisateur unique** partageant le noyau de l'OS hôte.
+
+## Explication Détaillée
+Contrairement à une VM (qui virtualise le hardware), un conteneur virtualise uniquement l'OS. Avantages : démarrage en ms, densité élevée (centaines par host), empreinte disque/RAM minimale.
+
+Composants clés :
+- **Runtime** : containerd, runc, CRI-O.
+- **Image** : système de fichiers layeré (UnionFS).
+- **Registry** : Docker Hub, GHCR, Quay.
+- **Orchestration** : Kubernetes, Nomad, Docker Swarm.
+
+## Cas d'Usage
+- Déploiement d'applications web.
+- Reproductibilité des environnements de dev/prod.
+- Microservices.
+- Self-hosting.
+
+## Outils Liés
+- **[[docker]]** (le plus connu).
+- **Podman** (rootless, alternative à Docker).
+- **LXC/LXD** (system containers, plus proches d'une VM).
+- **Kubernetes** (orchestration à grande échelle).
+
+## Pages Liées
+- [[docker]]
+- [[architecture-microservices]]
+- [[securisation-home-lab]]
+
+## Questions Ouvertes
+- Les conteneurs vont-ils remplacer les VMs pour tout ?
+- Quelle est la limite de densité raisonnable par hôte ?
+
+## Liens
+- [[kubernetes]]

concepts/cryptographie-post-quantique.md

@@ -0,0 +1,37 @@
+---
+title: Cryptographie Post-Quantique (PQC)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, protocol, architecture-system]
+sources: [raw/articles/cours-pqc.md]
+confidence: high
+contested: false
+---
+# 🛡️ Cryptographie Post-Quantique (PQC)
+
+La **Cryptographie Post-Quantique** désigne l'ensemble des algorithmes de chiffrement conçus pour être sécurisés face à la puissance de calcul des futurs ordinateurs quantiques. Contrairement à la cryptographie quantique, la PQC s'exécute sur des ordinateurs classiques.
+
+## Le Danger Quantique
+Le risque principal provient de l'**Algorithme de Shor**, capable de factoriser des nombres premiers et de résoudre des problèmes de logarithmes discrets, rendant obsolètes les standards actuels comme RSA et ECC. 
+
+Un concept critique est l'attaque **"Harvest Now, Decrypt Later"**, où des données sont capturées aujourd'hui pour être déchiffrées ultérieurement grâce à une machine quantique.
+
+## Principes Techniques
+La PQC s'appuie sur des problèmes mathématiques dont on ne connaît pas de solution efficace, même avec des qubits. La méthode la plus robuste est la **cryptographie sur les réseaux euclidiens** (Lattice-based cryptography).
+
+- **Analogie** : Retrouver un point précis dans un réseau multidimensionnel (ex: 500D) avec un bruit aléatoire ajouté, ce qui rend l'optimisation impossible pour un attaquant.
+
+## Standards et Implémentations
+Le **NIST** a officialisé en 2024 les standards suivants :
+- **ML-KEM (Kyber)** : Utilisé pour le chiffrement et les échanges de clés (TLS/HTTPS).
+- **ML-DSA (Dilithium)** : Dédié aux signatures numériques.
+
+Une approche prudente consiste à utiliser des **systèmes hybrides**, comme dans [[openssh]], mêlant ECC classique et PQC.
+
+## Liens
+- Protocole concerné : [[tls-https]]
+- Application : [[openssh]]
+- Domaine : [[security]]
+- [[hash-cryptographique]]
+- [[cours-pqc]]

concepts/customer-feedback-loop.md

@@ -0,0 +1,17 @@
+---
+title: Customer Feedback Loop (Alias)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [business, product, strategy]
+confidence: medium
+contested: false
+sources: []
+---
+# 🔁 Customer Feedback Loop (Alias)
+
+Cette page est un alias de [[boucle-feedback-client]].
+
+## Pages Liées
+- [[boucle-feedback-client]]
+- [[pricing-strategy]]

concepts/deploiement-blue-green.md

@@ -0,0 +1,56 @@
+---
+title: Déploiement Blue-Green
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [devops, architecture, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔵 Déploiement Blue-Green
+
+## Définition Courte
+Stratégie de déploiement qui maintient **deux environnements identiques** (Blue et Green) et bascule le trafic de l'un à l'autre instantanément, permettant un **rollback immédiat** en cas de problème.
+
+## Explication Détaillée
+**Principe** :
+- Blue = version actuelle en production.
+- Green = nouvelle version, déployée mais ne reçoit pas (encore) le trafic.
+- Tests sont exécutés sur Green (smoke tests, canary interne).
+- Bascule du load balancer : tout le trafic va sur Green.
+- Blue devient l'environnement de rollback (stand-by).
+
+**Avantages** : 
+- Zéro downtime (la bascule est instantanée).
+- Rollback en 1 seconde (re-basculer).
+- Pas de "version N+1" partielle, tout le monde est sur la même version.
+
+**Inconvénients** : 
+- Double infrastructure (coût).
+- Gestion des migrations de BDD délicate.
+- Pas de progression graduelle (vs canary).
+
+## Cas d'Usage
+- Apps avec SLA serré (zéro downtime).
+- Déploiements critiques (banque, e-commerce).
+- Bases de données compatibles avec un switch rapide.
+
+## Outils Liés
+- **Kubernetes** : services + labels, rollout de Deployment.
+- **AWS** : Elastic Beanstalk, CodeDeploy.
+- **Cloudflare Load Balancer** : pools de serveurs.
+
+## Pages Liées
+- [[canary-deployment]]
+- [[ci-cd]]
+- [[load-balancing]]
+- [[checklist-mise-en-production]]
+- [[haute-disponibilite]]
+
+## Questions Ouvertes
+- Blue-Green vs Canary : quand choisir l'un ou l'autre ?
+- Comment gérer les migrations de schéma DB pendant un blue-green ?
+
+## Liens
+- [[feature-flags]]

concepts/deploiement-canary.md

@@ -0,0 +1,55 @@
+---
+title: Déploiement Canary
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [devops, architecture, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🐤 Déploiement Canary
+
+## Définition Courte
+Stratégie qui **déploie progressivement** une nouvelle version à un petit pourcentage d'utilisateurs (les "canaris"), surveille les métriques, puis étend si tout va bien.
+
+## Explication Détaillée
+**Étapes typiques** :
+1. Déployer la v2 sur 1% du parc.
+2. Surveiller pendant X minutes (erreurs, latence, CPU).
+3. Si OK, étendre à 10%, 25%, 50%, 100%.
+4. Si problème à une étape, rollback instantané.
+5. Une fois à 100%, décommissionner la v1.
+
+**Critères d'analyse** :
+- Taux d'erreur 5xx.
+- Latence p95/p99.
+- Métriques métier (conversion, rétention).
+- CPU/RAM inhabituel.
+
+**Comparaison** :
+- **Blue-Green** : tout bascule d'un coup.
+- **Canary** : bascule progressive, plus granulaire.
+- **Feature Flags** : contrôle par user, pas par % global.
+
+## Cas d'Usage
+- Apps à fort trafic où un bug toucherait beaucoup d'utilisateurs.
+- Refonte majeure (changement d'architecture).
+- Modèles ML (peut-être que la nouvelle version dégrade la qualité).
+
+## Outils Liés
+- **Kubernetes** : Argo Rollouts, Flagger.
+- **Istio** : traffic shifting basé sur poids.
+- **AWS CodeDeploy**, **Google Cloud Deploy**.
+- **LaunchDarkly**, **Flagsmith** (feature flag services).
+
+## Pages Liées
+- [[deploiement-blue-green]]
+- [[feature-flags]]
+- [[ci-cd]]
+- [[observabilite]]
+- [[chaos-engineering]]
+
+## Questions Ouvertes
+- Combien de temps faut-il observer à chaque étape ?
+- Comment choisir le critère de promotion automatique vs manuel ?

concepts/docker-compose.md

@@ -0,0 +1,17 @@
+---
+title: Docker Compose (Alias)
+created: 2026-06-06
+updated: 2026-06-06
+type: entity
+tags: [tech, docker, open-source]
+confidence: medium
+contested: false
+sources: []
+---
+# 🐳 Docker Compose (Alias)
+
+Cette page est un alias de [[docker]].
+
+## Pages Liées
+- [[docker]]
+- [[conteneurisation]]

concepts/edge-computing.md

@@ -0,0 +1,46 @@
+---
+title: Edge Computing
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, architecture, cloud]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🌍 Edge Computing
+
+## Définition Courte
+Paradigme qui rapproche le calcul et le stockage des données de l'endroit où elles sont produites ou consommées, plutôt que de tout centraliser dans un datacenter cloud.
+
+## Explication Détaillée
+L'edge computing réduit la latence en traitant les données au plus près de la source. Cela inclut :
+- **CDN Edge** : Cloudflare Workers, Fastly Compute.
+- **5G/MEC** : calcul dans l'antenne télécom.
+- **IoT** : calcul sur l'appareil ou la gateway locale.
+- **On-device** : inférence IA sur le téléphone (CoreML, TFLite).
+
+**Avantages** : latence ultra-faible, bande passante économisée, résilience (pas de dépendance réseau), privacy (données locales).
+**Inconvénients** : puissance limitée, orchestration complexe, debugging difficile.
+
+## Cas d'Usage
+- Personnalisation web géolocalisée.
+- IoT industriel (latence critique).
+- Inférence IA sur mobile.
+- Jeux cloud (GeForce Now, Stadia-like).
+
+## Outils Liés
+- **Cloudflare Workers**, **Vercel Edge Functions**, **Deno Deploy**.
+- **Fastly Compute@Edge**.
+- **K3s** (Kubernetes léger pour edge).
+
+## Pages Liées
+- [[server-side-rendering]]
+- [[concepts-web]]
+
+## Questions Ouvertes
+- L'edge va-t-il remplacer le cloud centralisé pour les cas légers ?
+- Comment orchestrer des déploiements sur des milliers d'edge nodes ?
+
+## Liens
+- [[webassembly]]

concepts/embeddings.md

@@ -0,0 +1,43 @@
+---
+title: Embeddings
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, ML, data]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🌌 Embeddings
+
+## Définition Courte
+Représentation **vectorielle dense** d'une donnée (texte, image, audio) dans un espace de grande dimension (ex: 768, 1024, 4096) où la **proximité géométrique** reflète la **proximité sémantique**.
+
+## Explication Détaillée
+Un embedding transforme "Le chat dort" en un vecteur `[0.12, -0.45, 0.78, ...]`. Deux phrases de sens proche auront des vecteurs proches (cosine similarity élevée).
+
+Modèles populaires :
+- **OpenAI** : `text-embedding-3-small/large`.
+- **Cohere** : `embed-english-v3.0`.
+- **Hugging Face** : BGE, E5, Nomic Embed (open-weights).
+
+**Cas d'usage** : recherche sémantique, RAG, classification, recommandation, détection d'anomalies.
+
+## Cas d'Usage
+- Base de connaissances RAG.
+- Recherche de doublons.
+- Clustering de documents.
+- Recommandation de produits.
+
+## Outils Liés
+- **Bases vectorielles** : Qdrant, Chroma, Weaviate, Pinecone, pgvector (Postgres).
+- **Modèles** : OpenAI, Cohere, BGE, Nomic.
+
+## Pages Liées
+- [[rag]]
+- [[glossaire-ia]]
+- [[comparatif-stockage]]
+
+## Questions Ouvertes
+- Quelle dimension d'embedding choisir (trade-off mémoire vs précision) ?
+- Les embeddings vont-ils être remplacés par des modèles plus unifiés ?

concepts/feature-flags.md

@@ -0,0 +1,49 @@
+---
+title: Feature Flags
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [devops, tech, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🚩 Feature Flags
+
+## Définition Courte
+Mécanisme permettant d'**activer ou désactiver une fonctionnalité** à distance, **sans redéployer**, souvent ciblé par utilisateur, segment ou pourcentage.
+
+## Explication Détaillée
+Le code de la feature est déployé, mais reste "off" tant que le flag n'est pas activé. Cela permet :
+- **Trunk-based development** : merge fréquent en main, feature off jusqu'à release.
+- **Découplage** : le déploiement (technique) est séparé de la release (business).
+- **Kill switch** : couper une feature en prod en 1 clic.
+- **A/B testing** : 50% des users voient la vA, 50% la vB.
+- **Beta privé** : activer pour 100 users triés sur le volet.
+
+**Types** :
+- **Boolean** : on/off simple.
+- **Multivariate** : plusieurs variants (A/B/C).
+- **Targeted** : règle complexe (user.email contains "@acme.com").
+- **Percentage rollout** : 1%, 10%, 50%...
+
+## Cas d'Usage
+- Lancement progressif d'une feature majeure.
+- Dark launch (test de charge en prod).
+- Personnalisation par plan tarifaire.
+- Désactivation rapide d'un service tiers en panne.
+
+## Outils Liés
+- **Open-source** : Unleash, Flagsmith, GrowthBook.
+- **SaaS** : LaunchDarkly, Split.io.
+- **DIY** : simple config DB + middleware.
+
+## Pages Liées
+- [[deploiement-canary]]
+- [[deploiement-blue-green]]
+- [[ci-cd]]
+- [[a-b-testing]]
+
+## Questions Ouvertes
+- Les feature flags finissent-ils toujours en dette technique (jamais retirés) ?
+- Comment éviter que l'équipe passe son temps à gérer les flags ?

concepts/fine-tuning.md

@@ -0,0 +1,50 @@
+---
+title: Fine-Tuning
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, training, model]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🎓 Fine-Tuning
+
+## Définition Courte
+Processus d'entraînement **additionnel** d'un modèle pré-entraîné sur un dataset spécifique pour le spécialiser dans une tâche ou un domaine.
+
+## Explication Détaillée
+Le fine-tuning ajuste les poids d'un modèle en partant d'un modèle de base (ex: Llama 3.1 8B) et en l'entraînant sur des données ciblées (ex: jurisprudence française, code Python interne, ton d'une marque).
+
+Techniques modernes :
+- **Full Fine-Tuning** : ajuste tous les poids (coûteux).
+- **LoRA / QLoRA** : ne modifie qu'une petite partie, beaucoup plus léger.
+- **PEFT** : Parameter-Efficient Fine-Tuning (famille de techniques).
+
+Alternative : le **RAG** qui ajoute des connaissances à la volée, sans modifier le modèle.
+
+## Cas d'Usage
+- Adapter un LLM à un jargon métier (médical, juridique).
+- Modifier le ton et le style de réponse.
+- Apprendre un format de sortie strict (JSON, SQL).
+
+## Outils Liés
+- **Hugging Face Transformers / TRL**.
+- **Unsloth** (fine-tuning rapide, optimise VRAM).
+- **Axolotl**, **LLaMA-Factory**.
+- **Replicate**, **Modal** (inférence fine-tunée en SaaS).
+
+## Pages Liées
+- [[lora]]
+- [[rag]]
+- [[llama-3-1]]
+- [[glossaire-ia]]
+
+## Questions Ouvertes
+- À partir de quelle taille de dataset le fine-tuning devient rentable vs RAG ?
+- Le fine-tuning va-t-il devenir accessible au grand public (UI no-code) ?
+
+## Liens
+- [[reinforcement-learning]]
+- [[outils-nocode-solo-dev]]
+- [[hermes-agent]]

concepts/firewall.md

@@ -0,0 +1,47 @@
+---
+title: Firewall
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, networking, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔥 Firewall
+
+## Définition Courte
+Système (logiciel ou matériel) qui **filtre le trafic réseau** entrant et sortant selon des règles définies. C'est la première ligne de défense d'un serveur.
+
+## Explication Détaillée
+Deux grandes familles sous Linux :
+- **nftables** (successeur de iptables) : framework moderne, syntaxe simplifiée, meilleures performances.
+- **ufw** (Uncomplicated Firewall) : frontend simplifié à iptables/nftables, idéal pour débuter.
+
+Concepts clés :
+- **Politique par défaut** : deny all incoming, allow established.
+- **Chaînes** (INPUT, OUTPUT, FORWARD) : points d'inspection du trafic.
+- **Règles** : matching (port, IP, protocole) + action (ACCEPT, DROP, REJECT).
+- **Rate limiting** : limitation du nombre de connexions par IP.
+
+**Au niveau cloud** : Security Groups (AWS), Network Security Groups (Azure), VPC firewall (GCP).
+
+## Cas d'Usage
+- Bloquer tout sauf SSH + 80/443 sur un VPS.
+- Isoler des conteneurs Docker sur des réseaux internes.
+- Protéger une base de données accessible uniquement depuis le réseau interne.
+
+## Outils Liés
+- **nftables** (kernel), **iptables** (legacy).
+- **ufw** (Ubuntu), **firewalld** (RHEL/Fedora).
+- **CrowdSec** (cf. [[crowdsec]]), **fail2ban** (cf. [[fail2ban]]) : pare-feux applicatifs.
+
+## Pages Liées
+- [[securisation-home-lab]]
+- [[checklist-securite-vps]]
+- [[glossaire-homelab]]
+- [[vpn]]
+
+## Questions Ouvertes
+- nftables va-t-il définitivement enterrer iptables ?
+- Le firewall d'application (WAF) remplace-t-il le firewall réseau ?

concepts/function-calling.md

@@ -0,0 +1,53 @@
+---
+title: Function Calling
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, agent, protocol]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🛠️ Function Calling
+
+## Définition Courte
+Mécanisme permettant à un LLM de **produire un appel structuré** vers une fonction externe (outil) plutôt que du texte libre, déclenchant ainsi une action dans le monde réel.
+
+## Explication Détaillée
+Au lieu de demander au LLM "quel temps fait-il ?", on lui fournit une description d'outil (`get_weather(city: str)`) et le LLM répond :
+```json
+{"name": "get_weather", "arguments": {"city": "Lyon"}}
+```
+Le système exécute alors la fonction et réinjecte le résultat dans la conversation.
+
+C'est la **brique atomique** de l'agentique : sans function calling, un LLM ne peut qu'émettre du texte.
+
+**Pipeline** :
+1. Définir les outils (nom, description, schéma JSON des arguments).
+2. Envoyer la requête avec ces outils.
+3. Le LLM choisit s'il appelle un outil et avec quels arguments.
+4. Exécuter l'outil côté code.
+5. Renvoyer le résultat au LLM.
+6. Le LLM produit la réponse finale (ou appelle un autre outil).
+
+## Cas d'Usage
+- Agents autonomes (cf. [[hermes-agent]]).
+- Accès à des API (base de données, calendrier, mail).
+- Calcul précis (le LLM délègue à Python).
+- Recherche web (cf. [[react-framework]]).
+
+## Outils Liés
+- **OpenAI Function Calling**, **Anthropic Tool Use**.
+- **[[mcp-protocol]]** (standardisation multi-host).
+- **LangChain Tools**, **LlamaIndex Tools**.
+
+## Pages Liées
+- [[react-framework]]
+- [[hermes-agent]]
+- [[mcp-protocol]]
+- [[chain-of-thought]]
+- [[prompt-engineering-agents]]
+
+## Questions Ouvertes
+- Le function calling va-t-il totalement fusionner avec MCP ?
+- Comment fiabiliser le 100% de réussite sur des outils critiques (Stripe) ?

concepts/gitops.md

@@ -0,0 +1,42 @@
+---
+title: GitOps
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [devops, automation, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📜 GitOps
+
+## Définition Courte
+Paradigme où **Git est la source de vérité unique** pour les déploiements : l'état de l'infrastructure et des applications est décrit dans des repos Git, et des agents synchronisent en continu l'état réel avec l'état désiré.
+
+## Explication Détaillée
+GitOps combine IaC, CI/CD et les principes Git. Quand un dev push sur `main`, un agent (ArgoCD, Flux) détecte le changement et applique la nouvelle config.
+
+**Avantages** : traçabilité totale (qui a changé quoi, quand, pourquoi via les commits), rollback trivial (git revert), revue de code pour l'infra.
+**Inconvénients** : courbe d'apprentissage, nécessite un cluster Kubernetes (historiquement).
+
+## Cas d'Usage
+- Déploiements Kubernetes reproductibles.
+- Conformité et audit (tout est dans Git).
+- Disaster recovery automatisé.
+
+## Outils Liés
+- **ArgoCD** (CNCF, dashboard riche).
+- **Flux** (CNCF, plus minimaliste).
+- **Pulumi CrossCode**, **Spacelift**.
+
+## Pages Liées
+- [[ci-cd]]
+- [[infrastructure-as-code]]
+- [[architecture-microservices]]
+
+## Questions Ouvertes
+- GitOps est-il pertinent hors de Kubernetes ?
+- Quel est le futur de GitOps avec l'IA (auto-remediation) ?
+
+## Liens
+- [[kubernetes]]

concepts/glossaire-homelab.md

@@ -0,0 +1,39 @@
+---
+title: Glossaire Homelab
+created: 2026-06-06
+updated: 2026-06-06
+type: glossary
+tags: [auto-hébergement, glossary, networking, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📖 Glossaire Homelab & Infra
+
+Vocabulaire essentiel pour administrer un serveur domestique.
+
+- **Self-Hosting** : Le fait d'héberger soi-même ses services numériques sur sa propre machine.
+- **Home-Lab** : Le laboratoire/serveur installé à domicile pour apprendre, tester et auto-héberger.
+- **Container** : Environnement d'exécution isolé (ex: [[docker]]) qui partage le noyau du système hôte mais isole les processus.
+- **Image** : Modèle statique utilisé pour créer un conteneur (ex: `nginx:latest`).
+- **Docker Compose** : Outil pour définir et lancer des applications multi-conteneurs via un fichier YAML.
+- **Volume** : Mécanisme de persistance des données pour les conteneurs Docker.
+- **Reverse Proxy** : Serveur intermédiaire qui reçoit les requêtes externes et les distribue aux bons services internes. Ex: [[traefik]].
+- **SSL/TLS** : Protocoles de chiffrement des communications (utilisés en HTTPS).
+- **Let's Encrypt** : Autorité de certification gratuite et automatisée.
+- **Port** : Point d'entrée numérique sur une machine (0-65535). HTTP=80, HTTPS=443, SSH=22.
+- **LAN** : Réseau local (votre maison/bureau).
+- **WAN** : Réseau étendu (internet).
+- **NAT (Network Address Translation)** : Mécanisme du routeur qui permet à plusieurs appareils locaux de partager une IP publique.
+- **Port Forwarding** : Ouverture d'un port du routeur vers une machine du LAN, nécessaire pour exposer un service.
+- **VPN** : Réseau privé virtuel chiffré, utilisé pour accéder à son réseau de manière sécurisée depuis l'extérieur.
+- **Tailscale / WireGuard** : Solutions VPN modernes (mesh network) très faciles à déployer.
+- **NAS (Network Attached Storage)** : Serveur de stockage accessible sur le réseau.
+- **UPS (Onduleur)** : Batterie de secours protégeant contre les coupures de courant.
+- **RAID** : Agrégation de disques pour la redondance (RAID 1 = miroir, RAID 5/6 = parité).
+- **SSH (Secure Shell)** : Protocole d'accès distant sécurisé. Implémenté par [[openssh]].
+
+## Liens
+- Outils : [[docker]], [[traefik]], [[openssh]]
+- Concepts : [[securisation-home-lab]], [[strategie-backup-321]]
+- [[firewall]]

concepts/glossaire-ia.md

@@ -0,0 +1,37 @@
+---
+title: Glossaire IA
+created: 2026-06-06
+updated: 2026-06-06
+type: glossary
+tags: [IA, glossary, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📖 Glossaire IA pour Dev / Self-Hosting
+
+Définitions des termes essentiels pour comprendre et travailler avec l'Intelligence Artificielle localement.
+
+- **LLM (Large Language Model)** : Modèle de langage de grande taille, capable de générer du texte, de raisonner et d'utiliser des outils.
+- **Prompt** : L'instruction textuelle envoyée au modèle pour guider sa réponse.
+- **Context Window** : La quantité maximale de texte (en tokens) qu'un modèle peut traiter en une seule fois (ex: 8k, 128k).
+- **Token** : Unité de base du texte traité par le modèle (mot ou partie de mot).
+- **Quantization** : Processus de réduction de la précision des poids d'un modèle (ex: de FP16 à Q4) pour économiser de la RAM/VRAM. Formats courants : [[gguf]], [[exl2]].
+- **GGUF (GPT-Generated Unified Format)** : Format de fichier standard pour faire tourner des modèles via [[llama-cpp]] (utilisé par [[ollama]]).
+- **Inference** : Le processus par lequel le modèle génère une réponse à partir d'un prompt.
+- **Embeddings** : Représentation numérique (vecteur) d'un texte, permettant de calculer des similarités sémantiques (base du RAG).
+- **RAG (Retrieval-Augmented Generation)** : Technique consistant à fournir à un LLM des documents pertinents récupérés dans une base de connaissances pour améliorer ses réponses.
+- **Fine-Tuning** : Entraînement additionnel d'un modèle sur un dataset spécifique pour le spécialiser.
+- **LoRA (Low-Rank Adaptation)** : Technique de fine-tuning léger ne modifiant qu'une petite partie des poids, plus rapide et moins coûteux.
+- **Agent** : Programme qui utilise un LLM pour prendre des décisions et interagir avec des outils de manière autonome. Ex: [[hermes-agent]].
+- **RAG vs Fine-Tuning** : Le RAG ajoute des connaissances à la volée, le fine-tuning modifie le comportement intrinsèque.
+- **VRAM** : Mémoire vidéo (RAM GPU). Critique pour la vitesse d'inférence des modèles.
+- **Hallucination** : Phénomène où le modèle invente des informations factuellement incorrectes.
+
+## Liens
+- Outils : [[ollama]], [[llama-cpp]], [[hermes-agent]]
+- Modèles : [[llama-3-1]], [[mistral]]
+- Architecture : [[transformer-architecture]]
+- [[base-de-donnees-vectorielle]]
+- [[tokenisation]]
+- [[reinforcement-learning]]

concepts/glossaire-open-source.md

@@ -0,0 +1,36 @@
+---
+title: Glossaire Open Source
+created: 2026-06-06
+updated: 2026-06-06
+type: glossary
+tags: [open-source, glossary, legal]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📖 Glossaire Open Source & Licences
+
+Définitions pour comprendre l'écosystème du logiciel libre.
+
+- **Open Source** : Code source publiquement accessible, modifiable et redistribuable.
+- **Free Software** : Logiciel Libre. Met l'accent sur la liberté de l'utilisateur (vs "Free" = gratuit).
+- **FOSS / FLOSS** : Free (Libre) and Open Source Software.
+- **Copyleft** : Principe obligeant les œuvres dérivées à adopter la même licence. Garantit la liberté du code. Ex: [[gpl-v3]].
+- **Permissive** : Licence qui impose peu de restrictions sur l'usage ou la redistribution. Ex: [[mit]], [[apache-2]].
+- **MIT License** : Licence ultra-permissive, l'une des plus utilisées.
+- **Apache 2.0** : Licence permissive avec protection explicite contre les brevets.
+- **GPLv3** : Licence copyleft forte (GNU General Public License v3).
+- **BSL (Business Source License)** : Licence "source available" limitant l'usage commercial dans le cloud.
+- **SSPL (Server Side Public License)** : Licence copyleft imposant la libération de toute la stack serveur (utilisée par MongoDB).
+- **Fork** : Copie d'un projet open-source pour le modifier indépendamment.
+- **Upstream** : Le projet original dont forkent les contributeurs.
+- **Maintainer** : Personne en charge de la maintenance et des décisions sur un projet open-source.
+- **Contributor** : Personne qui propose des modifications (code, doc) à un projet.
+- **Pull Request (PR)** : Proposition de modification soumise au projet upstream.
+- **Issue** : Signalement de bug ou demande de fonctionnalité.
+- **SaaS (Software as a Service)** : Logiciel hébergé chez un fournisseur et accessible via le web.
+- **Cloud-Washing** : Pratique consistant à vendre un service autour d'un logiciel open-source sans contribuer en retour au projet.
+
+## Liens
+- Licences : [[licences-open-source]]
+- Concept : [[open-source]]

concepts/graphql.md

@@ -0,0 +1,38 @@
+---
+title: GraphQL
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, protocol, web]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 💻 ◈ GraphQL
+
+## Définition Courte
+Langage de requête pour APIs créé par Facebook (2012, open-sourcé en 2015) permettant au client de demander **exactement** les données dont il a besoin, en une seule requête.
+
+## Explication Détaillée
+Contrairement à REST où le serveur définit la forme des réponses, GraphQL inverse la donne : le client écrit une requête qui spécifie les champs. Un endpoint unique (`/graphql`) sert toutes les demandes.
+
+**Avantages** : évite le sur-fetching et le under-fetching, une seule requête pour des données multiples, schéma typé fort (introspection).
+**Inconvénients** : complexité côté serveur (resolvers, N+1 queries), caching HTTP classique cassé, rate limiting plus complexe.
+
+## Cas d'Usage
+- APIs avec des vues très variées (mobile + web + desktop).
+- Données fortement relationnelles (réseau social, e-commerce).
+- Frontend découplé d'un backend existant.
+
+## Outils Liés
+- **Serveurs** : Apollo Server, Hasura, Graphene, Mercurius.
+- **Clients** : Apollo Client, Relay, urql.
+- **Federation** : Apollo Federation, GraphQL Mesh.
+
+## Pages Liées
+- [[api-rest]]
+- [[concepts-web]]
+
+## Questions Ouvertes
+- La complexité de GraphQL est-elle justifiée pour des apps simples ?
+- Comment gérer l'auth fine par champ avec GraphQL ?

concepts/hash-cryptographique.md

@@ -0,0 +1,48 @@
+---
+title: Hash Cryptographique
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, crypto, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔨 Hash Cryptographique
+
+## Définition Courte
+Fonction mathématique qui transforme une donnée de **taille arbitraire** en une empreinte de **taille fixe**, avec des propriétés d'irréversibilité et d'unicité.
+
+## Explication Détaillée
+Propriétés d'une bonne fonction de hash :
+- **Déterministe** : même entrée $\rightarrow$ même sortie.
+- **Rapide** : calculer le hash doit être peu coûteux.
+- **Résistance à la pré-image** : difficile de retrouver l'entrée à partir du hash.
+- **Résistance aux collisions** : difficile de trouver deux entrées avec le même hash.
+- **Effet avalanche** : 1 bit changé en entrée $\rightarrow$ hash complètement différent.
+
+Familles :
+- **SHA-2** (SHA-256, SHA-512) : standard actuel.
+- **SHA-3** (Keccak) : alternative, structure différente.
+- **BLAKE2 / BLAKE3** : très rapide, moderne.
+- **MD5, SHA-1** : **cassés**, à ne plus utiliser.
+
+## Cas d'Usage
+- Vérification d'intégrité (checksums).
+- Stockage de mots de passe (avec sel et bcrypt/argon2).
+- Signatures numériques.
+- Blockchain.
+
+## Outils Liés
+- **OpenSSL** (sha256sum, etc.).
+- **HashiCorp Vault**.
+- **Bcrypt**, **Argon2** (pour mots de passe).
+
+## Pages Liées
+- [[cryptographie-post-quantique]]
+- [[tls-https]]
+- [[ml-kem]]
+
+## Questions Ouvertes
+- SHA-256 survivra-t-il à l'ordinateur quantique ?
+- Quand faut-il passer à Argon2 vs Bcrypt ?

concepts/haute-disponibilite.md

@@ -0,0 +1,50 @@
+---
+title: Haute Disponibilité (HA)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, architecture, devops]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 💪 Haute Disponibilité (HA)
+
+## Définition Courte
+Capacité d'un système à **rester opérationnel** malgré la panne d'un ou plusieurs de ses composants. Objectif : minimiser le downtime.
+
+## Explication Détaillée
+Mesures clés :
+- **Disponibilité** (en "9") : 99.9% = 8.76h/an de downtime, 99.99% = 52min/an.
+- **MTTR** (Mean Time To Repair) : temps moyen de réparation.
+- **MTBF** (Mean Time Between Failures) : temps moyen entre pannes.
+
+Stratégies :
+- **Redondance** : aucun SPOF (Single Point of Failure).
+- **Réplication** : données copiées sur plusieurs nœuds.
+- **Failover automatique** : bascule en cas de panne.
+- **Disaster Recovery** : plan B pour une catastrophe régionale.
+
+## Cas d'Usage
+- Services critiques (banque, e-commerce, santé).
+- APIs avec SLA contractualisés.
+- Bases de données de production.
+
+## Outils Liés
+- **Keepalived**, **Pacemaker/Corosync** (failover Linux).
+- **Galera**, **Patroni** (HA PostgreSQL).
+- **Redis Sentinel**, **Redis Cluster**.
+
+## Pages Liées
+- [[load-balancing]]
+- [[chaos-engineering]]
+- [[securisation-home-lab]]
+
+## Questions Ouvertes
+- Quel niveau de HA est suffisant pour une startup ?
+- Le cloud rend-il la HA triviale ou cache-t-elle des pièges ?
+
+## Liens
+- [[deploiement-blue-green]]
+- [[deploiement-canary]]
+- [[load-shedding]]

concepts/idempotence.md

@@ -0,0 +1,44 @@
+---
+title: Idempotence
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, automation, devops]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔁 Idempotence
+
+## Définition Courte
+Propriété d'une opération qui produit le **même résultat** qu'on l'exécute une ou plusieurs fois. Une requête réseau ou un script est idempotent si elle/il peut être réessayé sans danger.
+
+## Explication Détaillée
+**Exemples** :
+- `PUT /user/42 {"name": "Velli"}` est idempotent : l'état final est le même que vous l'appeliez 1 ou 10 fois.
+- `POST /users {"name": "Velli"}` n'est PAS idempotent : 10 appels créent 10 utilisateurs.
+- Un script Ansible est idempotent : l'appliquer deux fois ne change rien si l'état cible est déjà atteint.
+
+Les méthodes HTTP idempotentes par spec : `GET`, `HEAD`, `PUT`, `DELETE`, `OPTIONS`, `TRACE`.
+
+## Cas d'Usage
+- Retries réseau (crucial en microservices).
+- Infrastructure as Code (Terraform, Ansible).
+- Webhooks : le fournisseur peut renvoyer le même hook plusieurs fois.
+
+## Outils Liés
+- **Ansible** (idempotence native).
+- **Terraform** (plan/apply déterministe).
+- **Idempotency-Key** dans Stripe API.
+
+## Pages Liées
+- [[patterns-architecture]]
+- [[automatisation-dotfiles]]
+- [[concepts-web]]
+
+## Questions Ouvertes
+- Comment garantir l'idempotence sur des opérations bancaires ?
+- Quand faut-il sacrifier l'idempotence pour la performance ?
+
+## Liens
+- [[message-queue]]

concepts/infrastructure-as-code.md

@@ -0,0 +1,45 @@
+---
+title: Infrastructure as Code (IaC)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, devops, automation]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🏗️ Infrastructure as Code (IaC)
+
+## Définition Courte
+Pratique consistant à **définir l'infrastructure** (serveurs, réseaux, DNS, etc.) dans des fichiers de configuration versionnés, plutôt que via des clics manuels.
+
+## Explication Détaillée
+L'IaC permet :
+- **Reproductibilité** : recréer un environnement identique en une commande.
+- **Versionnement** : l'infra évolue comme du code (Git, PR, code review).
+- **Documentation vivante** : le code EST la doc.
+- **Disaster recovery** : reconstruction rapide.
+
+Deux approches :
+- **Déclaratif** : on décrit l'état final (Terraform, Pulumi, CloudFormation).
+- **Impératif** : on décrit les étapes (Ansible, Chef, Puppet).
+
+## Cas d'Usage
+- Déployer une stack cloud complète (VPC, EC2, RDS).
+- Gérer un parc de serveurs (on-prem ou cloud).
+- Provisionner un homelab reproductible.
+
+## Outils Liés
+- **Terraform** (HashiCorp) : standard multi-cloud.
+- **Pulumi** : IaC en vrais langages (TS, Python, Go).
+- **Ansible** : configuration + provisionnement.
+- **OpenTofu** : fork open-source de Terraform.
+
+## Pages Liées
+- [[automatisation-dotfiles]]
+- [[idempotence]]
+- [[docker]]
+
+## Questions Ouvertes
+- L'IaC a-t-il un coût initial trop élevé pour de très petits projets ?
+- Pulumi va-t-il remplacer Terraform ?

concepts/kubernetes.md

@@ -0,0 +1,49 @@
+---
+title: Kubernetes
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, devops, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ☸️ Kubernetes (K8s)
+
+## Définition Courte
+Système open-source d'**orchestration de conteneurs** initialement créé par Google. Automatise le déploiement, le scaling et la gestion d'applications conteneurisées.
+
+## Explication Détaillée
+Kubernetes abstrait l'infrastructure sous-jacente (on déclare "je veux 3 instances de cette app" et K8s s'occupe de les placer, les redémarrer, etc.).
+
+Concepts clés :
+- **Pod** : unité minimale (1+ conteneurs partageant réseau/storage).
+- **Deployment** : déclaration d'état (X replicas d'un pod).
+- **Service** : point d'accès stable aux pods (load balancing interne).
+- **Ingress** : routage HTTP externe.
+- **Namespace** : isolation logique.
+
+Alternatives : K3s (léger, homelab), Nomad (plus simple), Docker Swarm (plus simple encore).
+
+## Cas d'Usage
+- Microservices à grande échelle.
+- ML platforms (Kubeflow).
+- Apps multi-cloud.
+
+## Outils Liés
+- **K3s**, **K0s** (versions light pour homelab).
+- **Helm** (package manager).
+- **ArgoCD** / **Flux** (GitOps).
+- **Rancher**, **Portainer** (UI de gestion).
+
+## Pages Liées
+- [[conteneurisation]]
+- [[gitops]]
+- [[architecture-microservices]]
+
+## Questions Ouvertes
+- Kubernetes est-il overkill pour un homelab ?
+- Quelle sera la prochaine abstraction au-dessus de K8s ?
+
+## Liens
+- [[breaking-changes-ecosysteme]]

concepts/licences-open-source.md

@@ -0,0 +1,28 @@
+---
+title: Licences Open Source
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [open-source, tech, legal]
+sources: [raw/articles/veille-licences.md]
+confidence: high
+contested: false
+---
+# 📜 Licences Open Source
+
+La gestion des licences définit les droits de modification, de distribution et d'utilisation d'un logiciel.
+
+## Typologie des Licences
+- **Permissives** : ([[mit]], [[apache-2]]) Autorisent presque tout, y compris l'incorporation dans des produits propriétaires.
+- **Réciproques (Copyleft)** : ([[gpl-v3]]) Obligent tout projet dérivé à rester sous la même licence libre.
+- **Restrictives/Hybrides** : ([[bsl]], [[sspl]]) Limitent l'usage commercial dans le Cloud pour empêcher le "cloud-washing".
+
+## Enjeux
+Le basculement de projets majeurs vers des licences BSL marque une tension entre la volonté de garder un projet ouvert et la nécessité économique face aux fournisseurs de cloud.
+
+## Liens
+- Concept : [[open-source]]
+- Licences spécifiques : [[mit]], [[apache-2]], [[gpl-v3]]
+- [[monetisation-open-source]]
+- [[sorties-open-source-semaine]]
+- [[veille-licences]]

concepts/llm-wiki.md

@@ -0,0 +1,36 @@
+---
+title: LLM Wiki (Karpathy)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [wiki, knowledge-base, AI]
+confidence: medium
+contested: false
+sources: []
+---
+# 📚 LLM Wiki (Pattern Karpathy)
+
+## Définition Courte
+Méthode de gestion de connaissances inspirée par Andrej Karpathy : transformer des informations brutes en **base de connaissances interconnectée** en fichiers Markdown, comparable à ce wiki.
+
+## Explication Détaillée
+Contrairement au RAG (qui redécouvre les connaissances à chaque requête), le LLM Wiki **compile** les savoirs une fois et les garde à jour. Les références croisées sont déjà là, les contradictions sont flaggées.
+
+**3 couches** :
+- **Raw** : sources immuables.
+- **Wiki** : pages entités/concepts/comparaisons (agent-owned).
+- **Schema** : conventions et taxonomie.
+
+## Cas d'Usage
+- Knowledge management personnel.
+- Veille structurée.
+- Recherche long terme.
+
+## Outils Liés
+- Obsidian (interface idéale).
+- Agents IA (Hermes Agent).
+
+## Pages Liées
+- [[comparatif-outils-notes]]
+- [[hermes-agent]]
+- [[open-source]]

concepts/load-balancing.md

@@ -0,0 +1,47 @@
+---
+title: Load Balancing
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, networking, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ⚖️ Load Balancing
+
+## Définition Courte
+Répartition du trafic réseau entrant sur **plusieurs serveurs** (ou instances) pour améliorer la disponibilité, la scalabilité et les performances.
+
+## Explication Détaillée
+Un load balancer (LB) est l'aiguilleur du trafic. Stratégies de routage :
+- **Round Robin** : à tour de rôle.
+- **Least Connections** : vers l'instance la moins chargée.
+- **IP Hash** : affinité de session (même client $\rightarrow$ même serveur).
+- **Weighted** : certains serveurs reçoivent plus (hardware plus puissant).
+
+Couches :
+- **L4 (Transport)** : bas niveau (TCP/UDP), rapide, peu d'intelligence. (HAProxy, NLB AWS).
+- **L7 (Application)** : inspecte HTTP, routage par URL/header. (Traefik, Nginx, Envoy).
+
+## Cas d'Usage
+- Scaler horizontalement une app web.
+- Déploiement blue/green.
+- Failover automatique.
+
+## Outils Liés
+- **HAProxy**, **Nginx**, **Traefik**.
+- **Envoy** (service mesh).
+- **AWS ALB/NLB**, **Cloudflare Load Balancer**.
+
+## Pages Liées
+- [[haute-disponibilite]]
+- [[architecture-microservices]]
+- [[traefik]]
+
+## Questions Ouvertes
+- L4 vs L7 : comment choisir ?
+- Comment faire du load balancing stateful (WebSocket, gaming) ?
+
+## Liens
+- [[cache]]

concepts/load-shedding.md

@@ -0,0 +1,49 @@
+---
+title: Load Shedding
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [architecture, devops, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ✂️ Load Shedding
+
+## Définition Courte
+Stratégie consistant à **rejeter délibérément certaines requêtes** sous forte charge pour **préserver la stabilité** du service, plutôt que de tout laisser s'effondrer.
+
+## Explication Détaillée
+**Principe** : quand un système sature, accepter de perdre quelques requêtes pour éviter de perdre *toutes* les requêtes. C'est un compromis explicite disponibilité/charge.
+
+**Stratégies** :
+- **Priority-based** : rejeter d'abord les clients bas-priorité (free users avant paid).
+- **Adaptive** : baisser la qualité des réponses (ex: pas d'images, pas de recommandations).
+- **Circuit Breaker** : couper un service en panne pour éviter l'effet domino.
+- **Queue-based** : accepter la requête, la mettre en file, refuser si la queue est pleine.
+- **Geographic** : couper certaines régions d'abord.
+
+**Différent du rate limiting** : le rate limiting est **préventif** (limite par user). Le load shedding est **réactif** (le système se protège globalement).
+
+## Cas d'Usage
+- API LLM en cas de pic de trafic soudain.
+- Plateforme de e-commerce pendant le Black Friday.
+- Service de paiement lors d'un incident bancaire.
+- Toute infra avec auto-scaling limité.
+
+## Outils Liés
+- **Hystrix** (Netflix, historique).
+- **Resilience4j** (Java).
+- **Polly** (.NET).
+- **Istio** (priority routing).
+- **Cloudflare** (rate limit adaptatif).
+
+## Pages Liées
+- [[haute-disponibilite]]
+- [[rate-limiting]]
+- [[circuit-breaker]]
+- [[chaos-engineering]]
+
+## Questions Ouvertes
+- Comment communiquer élégamment les rejets aux clients (UX) ?
+- Le load shedding peut-il être automatisé par IA (prédire la saturation) ?

concepts/lora.md

@@ -0,0 +1,45 @@
+---
+title: LoRA / QLoRA
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, training, optimization]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🎯 LoRA / QLoRA
+
+## Définition Courte
+**LoRA** (Low-Rank Adaptation) est une technique de fine-tuning qui n'ajuste qu'une **petite matrice** de poids (low-rank), réduisant drastiquement les coûts de calcul et de stockage.
+
+## Explication Détaillée
+Au lieu de modifier tous les poids d'un modèle de 7B paramètres, LoRA insère de petites matrices "adaptateurs" dans chaque couche et ne les entraîne que celles-là. Avantages :
+- Entraînement 10-100x plus rapide.
+- VRAM requise divisée par 3-10.
+- Adaptateurs de quelques Mo, faciles à stocker/distribuer.
+- Possibilité de switcher entre plusieurs adaptateurs sur un même modèle de base.
+
+**QLoRA** ajoute la **quantification 4-bit** du modèle de base pendant le fine-tuning, pour des économies encore plus massives.
+
+## Cas d'Usage
+- Fine-tuning sur un seul GPU grand public (RTX 4090).
+- Adapter un LLM à un domaine spécifique sans exploser le budget.
+- Créer plusieurs "personas" d'un même modèle.
+
+## Outils Liés
+- **Hugging Face PEFT** (implémentation officielle).
+- **Unsloth** (wrapper optimisé).
+- **bitsandbytes** (quantification pour QLoRA).
+
+## Pages Liées
+- [[fine-tuning]]
+- [[quantification-llm]]
+- [[llama-3-1]]
+
+## Questions Ouvertes
+- QLoRA est-il aussi bon qu'un full fine-tuning pour les tâches complexes ?
+- Combien d'adaptateurs peut-on empiler avant dégradation ?
+
+## Liens
+- [[reinforcement-learning]]

concepts/mcp-protocol.md

@@ -0,0 +1,46 @@
+---
+title: Model Context Protocol (MCP)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, protocol, agent]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔌 Model Context Protocol (MCP)
+
+## Définition Courte
+**Standard ouvert** lancé par Anthropic fin 2024 pour connecter des LLM à des **outils, données et prompts externes** de manière standardisée. Surnommé "le USB-C des LLM".
+
+## Explication Détaillée
+Avant MCP, chaque agent codait ses propres connecteurs vers ses outils. MCP uniformise via une architecture client/serveur :
+- **MCP Host** : l'application LLM (ex: Claude Desktop, IDE).
+- **MCP Client** : intégré au host, parle au serveur.
+- **MCP Server** : expose des **tools** (fonctions), des **resources** (données) et des **prompts** au LLM via JSON-RPC.
+
+**Avantages** : 
+- Un serveur MCP écrit une fois fonctionne avec tous les hosts compatibles.
+- Sécurité : sandbox et permissions explicites.
+- Réutilisabilité : communauté open-source de serveurs.
+
+## Cas d'Usage
+- Connecter un LLM à une base de code (via MCP Git).
+- Accès à des fichiers locaux (Filesystem MCP).
+- Recherche dans une base vectorielle.
+- Interaction avec des API tierces (GitHub, Slack, Notion).
+
+## Outils Liés
+- **SDK officiel** : Python, TypeScript, Rust, Go.
+- **Serveurs de référence** : filesystem, git, postgres, github.
+- **Registre** : mcpservers.org, awesome-mcp.
+
+## Pages Liées
+- [[hermes-agent]]
+- [[function-calling]]
+- [[react-framework]]
+- [[comparatif-orchestrateurs-agentiques]]
+
+## Questions Ouvertes
+- MCP va-t-il devenir le standard de fait comme LSP pour les IDE ?
+- Quel modèle de gouvernance pour les serveurs MCP tiers (sécurité) ?

concepts/message-queue.md

@@ -0,0 +1,56 @@
+---
+title: Message Queue
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, architecture, devops]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📨 Message Queue (File de Messages)
+
+## Définition Courte
+Composant d'architecture qui permet à des services d'**échanger des messages de manière asynchrone** via une file, découplant producteur et consommateur.
+
+## Explication Détaillée
+**Pattern de base** :
+- **Producer** envoie un message à un **topic** ou **queue**.
+- Le **broker** (le middleware) stocke le message de manière durable.
+- Un ou plusieurs **consumers** reçoivent le message et le traitent.
+- Si le consumer crashe, le message reste dans la queue et sera rejoué.
+
+**Patterns avancés** :
+- **Pub/Sub** : un message publié est lu par N consumers.
+- **Work Queue** : un message traité par un seul consumer (load balancing).
+- **Dead Letter Queue** : messages non traitables routés ailleurs.
+- **Idempotence** : le consumer doit gérer les doublons.
+
+**Garanties de livraison** :
+- **At most once** : le message est livré 0 ou 1 fois (peut être perdu).
+- **At least once** : livré au moins 1 fois (doublons possibles). **Le standard**.
+- **Exactly once** : 1 fois, jamais plus. Très coûteux (Kafka transactions).
+
+## Cas d'Usage
+- Communication asynchrone entre microservices.
+- Traitement de tâches lourdes en arrière-plan (envoi de mail, génération PDF).
+- Découplage de pics (lissage de charge).
+- Event Sourcing (cf. [[patterns-architecture]]).
+- IoT : ingestion massive de capteurs.
+
+## Outils Liés
+- **Kafka** : le standard, throughput massif, durable.
+- **RabbitMQ** : classique, AMQP, plus simple.
+- **NATS** : léger, pub/sub natif, idéal cloud-native.
+- **Redis Streams** : in-memory, rapide, simple.
+- **AWS SQS/SNS**, **GCP Pub/Sub**.
+
+## Pages Liées
+- [[architecture-microservices]]
+- [[patterns-architecture]]
+- [[idempotence]]
+- [[observabilite]]
+
+## Questions Ouvertes
+- Kafka est-il encore pertinent face à des solutions plus modernes (Redpanda, WarpStream) ?
+- Comment tester correctement des workflows asynchrones ?

concepts/meta.md

@@ -0,0 +1,23 @@
+---
+title: Meta (Facebook)
+created: 2026-06-06
+updated: 2026-06-06
+type: entity
+tags: [company, lab, open-source]
+confidence: medium
+contested: false
+sources: []
+---
+# 🏢 Meta (anciennement Facebook)
+
+**Meta** est la société mère de Facebook, Instagram, WhatsApp. C'est aussi un acteur majeur de l'IA open-source via Meta AI.
+
+## Contributions Notables
+- [[llama-3-1]] (famille de LLM open-weights).
+- PyTorch (framework ML).
+- React (framework frontend).
+- Cassandra, RocksDB (data).
+
+## Pages Liées
+- [[llama-3-1]]
+- [[open-source]]

concepts/microsoft.md

@@ -0,0 +1,23 @@
+---
+title: Microsoft
+created: 2026-06-06
+updated: 2026-06-06
+type: entity
+tags: [company, lab, open-source]
+confidence: medium
+contested: false
+sources: []
+---
+# 🏢 Microsoft
+
+**Microsoft** est un géant du logiciel ayant massivement investi dans l'IA générative (partenariat OpenAI) et l'open-source.
+
+## Contributions Notables
+- [[phi-3-5]] (SLM).
+- TypeScript, VS Code, .NET.
+- Azure (cloud).
+- GitHub (acquis en 2018).
+
+## Pages Liées
+- [[phi-3-5]]
+- [[open-source]]

concepts/mistral-ai.md

@@ -0,0 +1,25 @@
+---
+title: Mistral AI
+created: 2026-06-06
+updated: 2026-06-06
+type: entity
+tags: [company, lab, open-source]
+confidence: medium
+contested: false
+sources: []
+---
+# 🏢 Mistral AI
+
+**Mistral AI** est une start-up française fondée en 2023, spécialisée dans les LLM performants et open-weights.
+
+## Modèles Notables
+- [[mistral]] (Large 2, NeMo, etc.).
+- Codestral (code).
+- Mixtral (MoE).
+
+## Positionnement
+Souveraineté européenne, performance, ouverture (sans être full OSS).
+
+## Pages Liées
+- [[mistral]]
+- [[open-source]]

concepts/mixture-of-experts.md

@@ -0,0 +1,39 @@
+---
+title: Mixture of Experts (MoE)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, architecture, model]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🧠 Mixture of Experts (MoE)
+
+## Définition Courte
+Architecture de réseau de neurones qui **active seulement une partie** des paramètres ("experts") pour chaque token, permettant des modèles immenses avec un coût d'inférence modéré.
+
+## Explication Détaillée
+Dans un Transformer "dense" classique, chaque token passe par tous les paramètres. Dans un MoE :
+- Plusieurs "experts" (sous-réseaux) coexistent.
+- Un **routeur** (gating network) choisit top-1 ou top-2 experts par token.
+- Seuls les experts sélectionnés sont activés.
+
+**Exemple** : Mixtral 8x7B a 8 experts de 7B, mais n'en active que 2 $\rightarrow$ ~13B params actifs pour 47B total. Plus rapide qu'un 47B dense, plus performant qu'un 13B dense.
+
+## Cas d'Usage
+- Modèles LLM très grands à coût d'inférence maîtrisé.
+- Modèles multimodaux (un expert par modalité).
+
+## Outils Liés
+- **Modèles** : Mixtral, Phi-3.5 MoE, DeepSeek-V3, GPT-4 (rumored MoE).
+- **Frameworks** : vLLM (inférence MoE optimisée), TGI.
+
+## Pages Liées
+- [[phi-3-5]]
+- [[llama-3-1]]
+- [[glossaire-ia]]
+
+## Questions Ouvertes
+- Le MoE est-il l'avenir de tous les grands modèles ?
+- Comment fine-tuner un MoE (quel expert entraîner) ?

concepts/monetisation-open-source.md

@@ -0,0 +1,66 @@
+---
+title: Monétisation Open Source
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [business, open-source, strategy]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 💵 Monétisation Open Source
+
+## Définition Courte
+Ensemble des **stratégies permettant de générer des revenus** à partir d'un projet open-source sans trahir la philosophie du libre.
+
+## Explication Détaillée
+**Modèles principaux** :
+
+- **Donations / Sponsorship** : 
+  - GitHub Sponsors, Open Collective, Patreon.
+  - Adapté aux mainteners solo ou petits projets.
+  - Revenus souvent modestes mais stables.
+
+- **Open Core** :
+  - Le cœur est OSS, les features entreprises (SSO, audit, support) sont payantes.
+  - Exemples : GitLab, Sentry, Supabase.
+
+- **SaaS sur OSS** (Software as a Service) :
+  - Le code est libre, mais l'hébergement managé est payant.
+  - Exemples : MongoDB Atlas, Aiven, Confluent.
+  - Tension avec la licence (cf. [[licences-open-source]]).
+
+- **Dual Licensing** :
+  - Le code est dispo en GPL (libre) OU en licence commerciale (payante).
+  - Permet de "racheter" la GPL pour intégrer dans un produit propriétaire.
+  - Exemples : MySQL, MariaDB (anciennement), Qt.
+
+- **Support & Consulting** :
+  - Red Hat, Elastic (avant le pivot), Canonical.
+  - Vendre l'expertise, pas le code.
+
+- **Marketplace / Plugins** :
+  - L'OSS est gratuit, mais des plugins/add-ons sont payants.
+  - WordPress, VS Code, Obsidian.
+
+- **T-shirts & Merch** :
+  - Plus symbolique que rentable, mais excellent pour la comm'.
+
+## Cas d'Usage
+- Mainteners solo cherchant à vivre de leur projet.
+- Startups construisant un moat grâce à l'open-source.
+- Entreprises finançant des briques critiques.
+
+## Outils Liés
+- **GitHub Sponsors**, **Open Collective**.
+- **Stripe** (pour les paiements SaaS).
+- **FOSSA**, **Snyk** (gestion de licence).
+
+## Pages Liées
+- [[licences-open-source]]
+- [[open-source]]
+- [[pricing-strategy]]
+
+## Questions Ouvertes
+- Comment éviter la tension entre "open" et "paying customers" ?
+- Le dual licensing est-il encore viable à l'ère des licences BSL/SSPL ?

concepts/oauth-2.md

@@ -0,0 +1,44 @@
+---
+title: OAuth 2.0
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, protocol, web]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔓 OAuth 2.0
+
+## Définition Courte
+Protocole standard d'**autorisation déléguée** : permet à une application tierce d'accéder à des ressources d'un utilisateur sur un autre service, sans partager le mot de passe.
+
+## Explication Détaillée
+OAuth 2.0 (RFC 6749) définit 4 rôles :
+- **Resource Owner** : l'utilisateur.
+- **Client** : l'app qui veut accéder (ex: une app mobile).
+- **Authorization Server** : authentifie l'utilisateur et émet des tokens.
+- **Resource Server** : l'API qui héberge les données.
+
+**Flow le plus courant** (Authorization Code) : l'utilisateur est redirigé vers le provider (Google, GitHub), y consent, et un **access token** est renvoyé à l'app.
+
+À ne pas confondre avec **OpenID Connect (OIDC)** qui ajoute une couche d'**identité** par-dessus OAuth (permet de récupérer le profil utilisateur).
+
+## Cas d'Usage
+- "Se connecter avec Google/GitHub/Apple".
+- Accès d'API tierces (ex: une app accède à vos Google Drive).
+- Délégation d'accès entre services internes.
+
+## Outils Liés
+- **Keycloak** (self-host).
+- **Auth0**, **Clerk** (SaaS).
+- **Dex** (IdP pour Kubernetes).
+
+## Pages Liées
+- [[concepts-web]]
+- [[chiffrement-bout-en-bout]]
+- [[zero-trust]]
+
+## Questions Ouvertes
+- OAuth 2.1 va-t-il simplifier l'écosystème (moins de flows) ?
+- Les passkeys vont-ils remplacer OAuth à terme ?

concepts/observabilite.md

@@ -0,0 +1,44 @@
+---
+title: Observabilité
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [devops, tech, monitoring]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 👀 Observabilité
+
+## Définition Courte
+Capacité à comprendre l'état interne d'un système à partir de ses **outputs externes** (logs, métriques, traces). Va au-delà du simple monitoring.
+
+## Explication Détaillée
+Les 3 piliers :
+- **Logs** : événements discrets horodatés. (Loki, Elastic, Splunk).
+- **Métriques** : valeurs numériques agrégées dans le temps. (Prometheus, InfluxDB, Datadog).
+- **Traces** : parcours d'une requête à travers les services. (Jaeger, Tempo, Zipkin).
+
+L'observabilité permet de répondre à des questions **inconnues à l'avance** ("pourquoi ce service est-il lent sur ce chemin ?"), là où le monitoring répond à des questions connues ("le CPU est-il à 80% ?").
+
+## Cas d'Usage
+- Microservices distribués.
+- Debugging en production sans reproduction locale.
+- Détection d'anomalies.
+
+## Outils Liés
+- **Pile Grafana** : Loki + Prometheus + Tempo + Grafana.
+- **Datadog**, **New Relic** (SaaS).
+- **OpenTelemetry** : standard d'instrumentation.
+
+## Pages Liées
+- [[checklist-monitoring-minimal]]
+- [[ci-cd]]
+- [[architecture-microservices]]
+
+## Questions Ouvertes
+- Comment instrumenter du code legacy sans tout réécrire ?
+- Logs vs métriques vs traces : quand utiliser quoi ?
+
+## Liens
+- [[monitoring-solo-dev]]

concepts/open-source-monetization.md

@@ -0,0 +1,18 @@
+---
+title: Open Source Monetization (Alias)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [business, open-source, strategy]
+confidence: medium
+contested: false
+sources: []
+---
+# 💵 Open Source Monetization (Alias)
+
+Cette page est un alias de [[monetisation-open-source]].
+
+## Pages Liées
+- [[monetisation-open-source]]
+- [[pricing-strategy]]
+- [[licences-open-source]]

concepts/open-source.md

@@ -0,0 +1,30 @@
+---
+title: Open-Source
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [open-source, ecosystem]
+sources: [raw/articles/hermes-agent-docs.md]
+confidence: high
+contested: false
+---
+# 🌍 Open-Source
+
+L'Open-Source dans le contexte de l'IA désigne le développement de modèles, de jeux de données et d'outils dont le code et les poids sont accessibles publiquement.
+
+## Importance pour l'IA
+Permet une innovation décentralisée et une transparence accrue sur le fonctionnement des modèles, s'opposant aux modèles "boîte noire".
+
+## Exemples
+- Incursions de [[nous-research]] dans la création de modèles ouverts.
+- Standardisation des compétences via [[systeme-de-skills]].
+
+## Liens
+- Organisation : [[nous-research]]
+- Application : [[hermes-agent]]
+- [[monetisation-open-source]]
+- [[comparatif-outils-notes]]
+- [[sorties-open-source-semaine]]
+- [[penpot]]
+- [[reseau-decentralise]]
+- [[alternatives-gafam]]

concepts/open-webui.md

@@ -0,0 +1,30 @@
+---
+title: Open WebUI
+created: 2026-06-06
+updated: 2026-06-06
+type: entity
+tags: [IA, open-source, web]
+confidence: medium
+contested: false
+sources: []
+---
+# 💬 Open WebUI
+
+**Open WebUI** (anciennement Ollama WebUI) est l'interface web de référence pour discuter avec des LLM locaux via Ollama ou des API compatibles (OpenAI).
+
+## Fonctionnalités
+- Chat multi-modèles (Llama, Mistral, etc.).
+- Gestion des prompts système.
+- RAG intégré (upload de documents).
+- Multi-utilisateurs (auth, partage).
+- Génération d'images (Stable Diffusion).
+
+## Pages Liées
+- [[ollama]]
+- [[stack-ia-maison]]
+- [[llama-3-1]]
+- [[mistral]]
+- [[rag]]
+
+## Liens
+- [[stack-docker-ia]]

concepts/patterns-architecture.md

@@ -0,0 +1,37 @@
+---
+title: Patterns d'Architecture
+created: 2026-06-06
+updated: 2026-06-06
+type: glossary
+tags: [tech, architecture, design]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📐 Patterns d'Architecture pour Apps Perso
+
+Modèles d'architecture pour structurer ses applications personnelles (self-hosted ou cloud).
+
+- **Monolith vs Microservices** : Un monolithe est une application unique, les microservices sont des services indépendants découplés. Pour une app perso, le monolithe est souvent plus simple.
+- **Client-Server** : Architecture fondamentale où un client (front) consomme des services fournis par un serveur (back).
+- **MVC (Model-View-Controller)** : Pattern séparant les données (Model), l'interface (View) et la logique de contrôle.
+- **Event-Driven** : Architecture où les composants communiquent via des événements (pub/sub). Idéal pour des systèmes asynchrones.
+- **CQRS (Command Query Responsibility Segregation)** : Séparation des opérations d'écriture (Command) et de lecture (Query) pour optimiser les deux.
+- **Hexagonal (Ports & Adapters)** : Isole le cœur métier de la technique. Facilite les tests et le changement de base de données.
+- **Repository Pattern** : Abstraction de l'accès aux données. Le métier ne sait pas si les données viennent d'une DB, d'une API ou d'un fichier.
+- **Service Layer** : Couche intermédiaire qui orchestre les cas d'usage en combinant plusieurs repositories.
+- **Backend for Frontend (BFF)** : Backend spécifique à un type de client (Web, Mobile) qui agrège les microservices sous-jacents.
+- **12-Factor App** : Méthodologie de conception d'applications cloud-native (config via env, stateless, logs en stdout, etc.).
+- **Stateless** : Le serveur ne conserve aucun état entre deux requêtes (toute l'info est dans la requête). Facilite le scaling.
+- **Stateful** : Le serveur conserve l'état (sessions, fichiers). Plus simple pour de petits projets.
+- **Reverse Proxy Pattern** : Utiliser un proxy (ex: [[traefik]]) devant plusieurs services pour gérer le routage et le SSL.
+- **API Gateway** : Point d'entrée unique pour toutes les APIs d'un système, gérant auth, rate limiting et routage.
+- **Cache-Aside** : Pattern où l'application lit d'abord le cache, et en cas de miss, lit la source et remplit le cache.
+- **Sidecar Pattern** : Un conteneur auxiliaire déployé à côté du conteneur principal pour fournir des fonctionnalités transverses (logs, proxy, config).
+- **Choreography vs Orchestration** : En microservices, la chorégraphie laisse les services réagir aux événements ; l'orchestration utilise un coordinateur central.
+
+## Liens
+- Domaine : [[tech]]
+- Outil : [[traefik]]
+- [[message-queue]]
+- [[architecture-monolithique]]

concepts/pricing-strategy.md

@@ -0,0 +1,57 @@
+---
+title: Pricing Strategy
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [business, saas, strategy]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 💰 Pricing Strategy
+
+## Définition Courte
+Définition de la **structure de prix** d'un produit (gratuit, freemium, abonnement, usage-based, etc.) et de ses paliers, en fonction de la valeur perçue et du marché.
+
+## Explication Détaillée
+**Modèles de pricing SaaS classiques** :
+
+- **Flat Rate** : un prix unique, simple à comprendre. Limite la segmentation.
+- **Tiered (Freemium)** : 3-4 paliers (Free, Pro, Business), très répandu.
+- **Per-Seat** : prix par utilisateur (Slack, Notion). Favorise l'account expansion.
+- **Usage-Based (Pay-as-you-go)** : facturation à la consommation (tokens, requêtes, Go). Idéal pour APIs/IA.
+- **Tiered Usage** : paliers avec plafond, puis usage-based au-delà (Stripe).
+- **Hybrid** : base + variable (ex: $50/mois + $0.01 par token).
+- **One-time** : licence perpétuelle (rare en SaaS, courant en self-hosted).
+- **Open Core** : core gratuit, features premium payantes.
+
+**Psychologie** :
+- **Ancrage** : le palier le plus cher rend les autres "abordables".
+- **Décoy effect** : un palier intermédiaire existe pour faire paraître le haut raisonnable.
+- **Perte aversion** : "Vous économisez 30% par an" > "Vous payez 70%".
+- **Trial vs Free Tier** : trial = accès limité dans le temps, free = accès limité en features.
+
+## Cas d'Usage
+- SaaS B2B (Vercel, Linear, Notion).
+- APIs IA (OpenAI, Replicate, Hugging Face).
+- Outils dev (Stripe, Twilio).
+- Apps mobiles grand public.
+
+## Outils Liés
+- **Stripe** (facturation, metering, taxes).
+- **Paddle**, **Lemon Squeezy** (Merchant of Record, gère la TVA).
+- **Orb**, **Metronome** (usage-based billing).
+
+## Pages Liées
+- [[open-source-monetization]]
+- [[customer-feedback-loop]]
+- [[comparatif-llm-local]]
+- [[hebergement-llm-solo-dev]]
+
+## Questions Ouvertes
+- Freemium ou Trial : quel taux de conversion viser ?
+- L'usage-based est-il viable pour les apps à fort trafic (coût cloud non proportionnel) ?
+
+## Liens
+- [[monetisation-open-source]]
+- [[boucle-feedback-client]]

concepts/prompt-engineering-agents.md

@@ -0,0 +1,33 @@
+---
+title: Prompt Engineering pour Agents
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [AI, architecture, agent]
+sources: [raw/articles/prompt-engineering-agents.md]
+confidence: high
+contested: false
+---
+# Prompt Engineering pour Agents
+
+Le **Prompt Engineering pour Agents** est l'art de structurer les instructions pour transformer un LLM passif en un agent autonome capable d'utiliser des outils et de raisonner de manière stable.
+
+## Frameworks de Raisonnement
+Pour éviter les erreurs et les boucles, on utilise des structures de pensée :
+- **[[react-framework]]** : Cycle Pensée $\rightarrow$ Action $\rightarrow$ Observation. Idéal pour l'interaction avec des outils.
+- **[[chain-of-thought]]** : Décomposition étape par étape d'un problème complexe.
+
+## Optimisation du Contexte
+La gestion de la fenêtre de contexte est cruciale pour éviter l'oubli des directives système.
+- **Problématique** : Le phénomène "lost in the middle" où l'agent oublie les informations centrales d'un prompt trop long.
+- **Solution** : Utilisation de la **divulgation progressive**, comme implémenté dans le [[systeme-de-skills]] de [[hermes-agent]].
+
+## Bonnes Pratiques de Structuration
+- **Few-Shot Prompting** : L'utilisation d'exemples concrets pour guider le comportement.
+- **Délimiteurs** : Structurer le prompt avec des blocs clairs pour séparer les rôles et les données.
+
+## Liens
+- [[hermes-agent]]
+- Technique : [[systeme-de-skills]]
+- Architecture : [[transformer-architecture]]
+- [[function-calling]]

concepts/prompt-engineering.md

@@ -0,0 +1,43 @@
+---
+title: Prompt Engineering
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, agent, technique]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 💬 Prompt Engineering
+
+## Définition Courte
+Discipline consistant à **concevoir et optimiser** les instructions (prompts) envoyées à un LLM pour obtenir les résultats souhaités de manière fiable et reproductible.
+
+## Explication Détaillée
+Techniques clés :
+- **Zero-shot** : instruction directe, pas d'exemple.
+- **Few-shot** : 2-5 exemples dans le prompt pour montrer le format attendu.
+- **Chain-of-Thought (CoT)** : forcer le raisonnement étape par étape.
+- **ReAct** : cycle Raisonnement + Action (outils).
+- **System Prompt** : instructions de rôle stables en début de prompt.
+- **Prompt Chaining** : décomposer une tâche en sous-prompts.
+- **Temperature / Top-P** : contrôler la créativité.
+
+## Cas d'Usage
+- Améliorer la qualité des réponses LLM sans changer de modèle.
+- Construire des agents autonomes.
+- Fiabiliser des sorties structurées (JSON, SQL).
+
+## Outils Liés
+- **LangChain**, **LlamaIndex** (frameworks).
+- **PromptLayer**, **LangSmith** (observabilité des prompts).
+- **Guidance**, **Outlines** (structured generation).
+
+## Pages Liées
+- [[prompt-engineering-agents]]
+- [[react-framework]]
+- [[chain-of-thought]]
+
+## Questions Ouvertes
+- Le prompt engineering va-t-il disparaître avec l'amélioration des modèles ?
+- Comment versionner et tester des prompts sérieusement ?

concepts/quantification-llm.md

@@ -0,0 +1,29 @@
+---
+title: Quantification LLM
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [architecture, tech, automation]
+sources: [raw/articles/fiches-modeles-llm.md]
+confidence: high
+contested: false
+---
+# 💻 Quantification LLM
+
+La quantification est le processus de réduction de la précision des poids d'un modèle (ex: passer de FP16 à INT4) pour diminuer l'empreinte mémoire et augmenter la vitesse d'inférence.
+
+## Formats Principaux
+
+### GGUF (llama.cpp)
+Format universel permettant l'exécution sur CPU et GPU. 
+- **Commande type** : `./quantize model.fp16.gguf model.q4_k_m.gguf q4_k_m`
+- **Avantage** : Compatibilité maximale (Ollama, llama.cpp).
+
+### EXL2 (ExLlamaV2)
+Format optimisé pour la VRAM des GPU Nvidia.
+- **Commande type** : `python convert.py -m model_dir -o quant_dir -q 4.0`
+- **Avantage** : Vitesse d'inférence extrêmement élevée.
+
+## Liens
+- Modèles compatibles : [[llama-3-1]], [[mistral]], [[phi-3-5]]
+- [[fiches-modeles-llm]]

concepts/rag.md

@@ -0,0 +1,48 @@
+---
+title: RAG (Retrieval-Augmented Generation)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, architecture, agent]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔍 RAG (Retrieval-Augmented Generation)
+
+## Définition Courte
+Architecture qui **augmente** un LLM en lui fournissant des documents pertinents récupérés dans une base de connaissances au moment de la requête, pour générer une réponse informée.
+
+## Explication Détaillée
+Étapes :
+1. **Ingestion** : découper les documents en chunks, les transformer en **embeddings**, les stocker dans une base vectorielle.
+2. **Retrieval** : à la question de l'utilisateur, on calcule l'embedding de la question, on cherche les chunks les plus similaires.
+3. **Augmentation** : on injecte ces chunks dans le prompt du LLM.
+4. **Generation** : le LLM répond en s'appuyant sur le contexte fourni.
+
+**Avantages vs fine-tuning** : pas d'entraînement, données toujours à jour, traçabilité des sources.
+**Inconvénients** : dépendance à la qualité du retrieval, taille de contexte limitée.
+
+## Cas d'Usage
+- Chatbot de support client (base de connaissances).
+- Assistant de documentation interne.
+- Recherche sémantique dans une bibliothèque.
+
+## Outils Liés
+- **Vectoriels** : Qdrant, ChromaDB, Weaviate, Pinecone.
+- **Frameworks** : LangChain, LlamaIndex, Haystack.
+- **Embeddings** : OpenAI, Cohere, BGE, Nomic Embed.
+
+## Pages Liées
+- [[fine-tuning]]
+- [[glossaire-ia]]
+- [[comparatif-stockage]]
+
+## Questions Ouvertes
+- Comment évaluer la qualité d'un pipeline RAG ?
+- Le RAG va-t-il fusionner avec les longs contextes (1M+ tokens) ?
+
+## Liens
+- [[base-de-donnees-vectorielle]]
+- [[tokenisation]]
+- [[base-de-donnees-solo-dev]]

concepts/rate-limiting.md

@@ -0,0 +1,53 @@
+---
+title: Rate Limiting
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, security, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ⏱️ Rate Limiting
+
+## Définition Courte
+Mécanisme qui **limite le nombre de requêtes** qu'un client peut faire sur une période donnée, pour protéger un service contre les abus et les surcharges.
+
+## Explication Détaillée
+**Algorithmes courants** :
+- **Fixed Window** : compteur par fenêtre de temps (ex: 100 req/minute). Simple, mais burst aux limites.
+- **Sliding Window** : fenêtre glissante, plus précis.
+- **Token Bucket** : réservoir de tokens, refillé à rythme constant. Gère bien les bursts.
+- **Leaky Bucket** : débit de sortie constant, lisse les pics.
+
+**Niveaux d'application** :
+- **L4 (TCP/UDP)** : limite de connexions par IP.
+- **L7 (HTTP)** : limite de requêtes par route, utilisateur, ou IP.
+- **API métier** : ex: 5 publications par heure par user.
+
+Headers HTTP standards : `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`, `Retry-After`.
+
+## Cas d'Usage
+- Protection contre les attaques par force brute (login).
+- Empêcher le scraping massif d'une API publique.
+- Protéger un backend LLM coûteux (limite de tokens/minute).
+- Éviter qu'un client monopolise un service partagé.
+
+## Outils Liés
+- **Redis** (Token Bucket rapide).
+- **NGINX** (`limit_req`, `limit_conn`).
+- **Traefik** (plugins rate-limit).
+- **Cloudflare** (rate limiting global).
+
+## Pages Liées
+- [[api-gateway]]
+- [[concepts-web]]
+- [[checklist-mise-en-production]]
+- [[securisation-home-lab]]
+
+## Questions Ouvertes
+- Comment différencier un bon client rapide d'un attaquant ?
+- Le rate limiting au niveau réseau (L4) est-il encore utile à l'ère du HTTPS everywhere ?
+
+## Liens
+- [[load-shedding]]

concepts/react-framework.md

@@ -0,0 +1,29 @@
+---
+title: ReAct Framework
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [AI, architecture, agent]
+sources: [raw/articles/prompt-engineering-agents.md]
+confidence: high
+contested: false
+---
+# 🔄 ReAct Framework
+
+**ReAct** (Reasoning and Acting) est un paradigme de prompt engineering qui permet à un agent d'interagir avec le monde réel en alternant raisonnement interne et actions externes.
+
+## Cycle de Fonctionnement
+Le cycle se répète jusqu'à la résolution de la tâche :
+1. **Pensée (Thought)** : L'agent analyse la situation et décide de l'action à mener.
+2. **Action** : L'agent appelle un outil (ex: recherche web, lecture de fichier).
+3. **Observation** : L'agent lit le résultat de l'action.
+4. **Nouvelle Pensée** : L'agent met à jour son état mental en fonction de l'observation.
+
+## Utilité
+Ce framework empêche l'agent de "deviner" la réponse when he lacks information, en le forçant à chercher la preuve via un outil avant de conclure.
+
+## Liens
+- Cadre général : [[prompt-engineering-agents]]
+- Agent utilisant ReAct : [[hermes-agent]]
+- [[transformer-architecture]]
+- [[function-calling]]

concepts/recettes-docker-compose.md

@@ -0,0 +1,96 @@
+---
+title: Recettes Docker Compose
+created: 2026-06-06
+updated: 2026-06-06
+type: recipe
+tags: [docker, automation, auto-hébergement]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📋 Recettes Docker Compose
+
+Snippets prêts à l'emploi pour vos stacks personnelles.
+
+## 1. Reverse Proxy Traefik + Service de Base
+```yaml
+services:
+  traefik:
+    image: traefik:v3.0
+    ports:
+      - "80:80"
+      - "443:443"
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock:ro
+      - ./letsencrypt:/letsencrypt
+    command:
+      - "--providers.docker=true"
+      - "--entrypoints.websecure.http.tls=true"
+      - "--certificatesresolvers.letsencrypt.acme.email=ton@email.com"
+      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
+
+  mon-app:
+    image: nginx:alpine
+    labels:
+      - "traefik.enable=true"
+      - "traefik.http.routers.monapp.rule=Host(`app.example.com`)"
+      - "traefik.http.routers.monapp.entrypoints=websecure"
+      - "traefik.http.routers.monapp.tls.certresolver=letsencrypt"
+```
+
+## 2. Stack IA Locale (Ollama + Open WebUI)
+```yaml
+services:
+  ollama:
+    image: ollama/ollama
+    container_name: ollama
+    ports:
+      - "11434:11434"
+    volumes:
+      - ollama_data:/root/.ollama
+    deploy:
+      resources:
+        reservations:
+          devices:
+            - driver: nvidia
+              count: all
+              capabilities: [gpu]
+    restart: unless-stopped
+
+  open-webui:
+    image: ghcr.io/open-webui/open-webui:main
+    container_name: open-webui
+    ports:
+      - "3000:8080"
+    environment:
+      - OLLAMA_BASE_URL=http://ollama:11434
+    volumes:
+      - openwebui_data:/app/backend/data
+    depends_on:
+      - ollama
+    restart: unless-stopped
+
+volumes:
+  ollama_data:
+  openwebui_data:
+```
+
+## 3. Sauvegarde Restic Automatisée
+```yaml
+services:
+  restic-backup:
+    image: mazzolino/restic-cron
+    environment:
+      - RESTIC_REPOSITORY=sftp:user@nas:/backups/maison
+      - RESTIC_PASSWORD=<mot_de_passe_fort>
+      - BACKUP_CRON=0 3 * * *  # Tous les jours à 3h du matin
+      - BACKUP_NAMES=vol1,vol2
+      - NFS_HOST=nas.local
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock:ro
+```
+
+## Liens
+- [[docker]], [[traefik]], [[ollama]], [[restic]]
+- Concepts : [[securisation-home-lab]], [[stack-ia-maison]]
+- [[deploiement-solo-dev]]

concepts/reinforcement-learning.md

@@ -0,0 +1,58 @@
+---
+title: Reinforcement Learning (RL)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, ML, training]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🎮 Reinforcement Learning (RL)
+
+## Définition Courte
+Paradigme d'apprentissage automatique où un **agent** apprend à prendre des décisions en **interagissant avec un environnement**, en maximisant une **récompense** cumulée.
+
+## Explication Détaillée
+**Les 4 concepts clés** :
+- **Agent** : le décideur (le modèle, le robot, le joueur).
+- **Environment** : le monde dans lequel il évolue.
+- **State** : la situation actuelle observée.
+- **Action** : ce que l'agent peut faire.
+- **Reward** : signal positif/négatif après une action.
+
+**Algorithmes majeurs** :
+- **Q-Learning / DQN** : apprendre une fonction de valeur.
+- **Policy Gradient (REINFORCE)** : optimiser directement la politique.
+- **PPO** (Proximal Policy Optimization) : standard en RLHF.
+- **A3C, SAC, TD3** : variantes pour des cas spécifiques.
+
+**RL + LLM** :
+- **RLHF** (RL from Human Feedback) : aligner le modèle sur les préférences humaines.
+- **DPO** (Direct Preference Optimization) : alternative plus simple, sans RL explicite.
+- **GRPO** (Group Relative Policy Optimization) : utilisé par DeepSeek-R1.
+- **RLAIF** : remplacer les humains par un autre LLM comme "juge".
+
+## Cas d'Usage
+- Jeux (AlphaGo, AlphaStar, OpenAI Five).
+- Robotique (locomotion, manipulation).
+- Trading algorithmique.
+- Alignement des LLM (cf. [[nouveautes-ia-par-mois]]).
+- Optimisation de ressources (data center cooling, Google).
+
+## Outils Liés
+- **Stable Baselines3** (Python).
+- **Ray RLlib** (distribué).
+- **Gymnasium** (anciennement OpenAI Gym, environnements).
+- **TRL** (Hugging Face, RLHF pour LLM).
+
+## Pages Liées
+- [[fine-tuning]]
+- [[lora]]
+- [[prompt-engineering]]
+- [[glossaire-ia]]
+- [[transformer-architecture]]
+
+## Questions Ouvertes
+- Le RL pur a-t-il un avenir face à l'apprentissage auto-supervisé à grande échelle ?
+- DPO va-t-il totalement remplacer RLHF ?

concepts/reseau-decentralise.md

@@ -0,0 +1,44 @@
+---
+title: Réseau Décentralisé
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, networking, open-source]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🌐 Réseau Décentralisé
+
+## Définition Courte
+Architecture réseau où **aucune autorité centrale** ne contrôle l'ensemble : les pairs (peers) coopèrent selon un protocole commun.
+
+## Explication Détaillée
+Différent du cloud centralisé (AWS, GCP) ou du modèle fédéré (Mastodon). Dans un réseau décentralisé pur, n'importe quel pair peut tomber ou partir, le réseau survit.
+
+**Exemples** :
+- **IPFS** : stockage de fichiers pair-à-pair.
+- **Matrix** : messagerie décentralisée.
+- **BitTorrent** : partage de fichiers.
+- **Ethereum / Bitcoin** : registres distribués.
+- **Tor** : anonymisation.
+
+## Cas d'Usage
+- Communication resistente à la censure.
+- Stockage redondant sans point central.
+- Monnaies numériques.
+
+## Outils Liés
+- **IPFS**, **Filecoin**.
+- **Matrix / Element**.
+- **Syncthing** (sync de fichiers pair-à-pair).
+- **Gun.js** (base de données décentralisée).
+
+## Pages Liées
+- [[matrix]]
+- [[vpn]]
+- [[glossaire-open-source]]
+
+## Questions Ouvertes
+- Comment modérer un réseau vraiment décentralisé ?
+- Le modèle décentralisé survivra-t-il à l'ubérisation (gros acteurs captent le réseau) ?

concepts/rotation-secrets.md

@@ -0,0 +1,51 @@
+---
+title: Rotation des Secrets
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, devops, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🔁 Rotation des Secrets
+
+## Définition Courte
+Pratique consistant à **renouveler périodiquement** les secrets (clés API, mots de passe, certificats, tokens) pour limiter l'impact d'une compromission.
+
+## Explication Détaillée
+**Pourquoi ?**
+- Si un secret fuite (log, repo Git, capture d'écran), la fenêtre de vulnérabilité est limitée.
+- Conformité (SOC2, ISO 27001, PCI-DSS imposent souvent une rotation).
+- Hygiène de base en production.
+
+**Stratégies** :
+- **Périodique** : tous les 30/60/90 jours.
+- **À la demande** : après un incident, un départ d'employé.
+- **Automatique** : via Vault, AWS Secrets Manager, Cloudflare R2.
+- **Zero-downtime** : courte overlap où les deux clés sont valides.
+
+**Certificats** : la rotation est devenue **critique** avec Let's Encrypt (90 jours max) et la promesse de certificats à 7 jours.
+
+## Cas d'Usage
+- Clés AWS / GCP / Azure.
+- Tokens de base de données.
+- API keys de services tiers (Stripe, OpenAI).
+- Certificats TLS.
+- Secrets Kubernetes.
+
+## Outils Liés
+- **HashiCorp Vault** (Dynamic Secrets, rotation auto).
+- **AWS Secrets Manager**, **GCP Secret Manager**.
+- **cert-manager** (Kubernetes, pour les certs).
+- **SOPS** + GitOps.
+
+## Pages Liées
+- [[secret-management]]
+- [[zero-trust]]
+- [[checklist-securite-vps]]
+- [[tls-https]]
+
+## Questions Ouvertes
+- Quelle fréquence optimale pour des secrets internes peu sensibles ?
+- Comment éviter les pannes pendant une rotation mal orchestrée ?

concepts/secret-management.md

@@ -0,0 +1,50 @@
+---
+title: Secret Management
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, tech, devops]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🤐 Secret Management
+
+## Définition Courte
+Pratique consistant à **stocker, distribuer et auditer** les secrets (clés API, mots de passe, certificats) de manière centralisée et sécurisée, plutôt que dans le code ou des fichiers `.env` partagés.
+
+## Explication Détaillée
+Mauvaises pratiques (à éviter) :
+- Secrets en dur dans le code.
+- `.env` commité dans Git.
+- Secrets partagés dans Slack/Email.
+
+Le Secret Management répond à :
+- **Centralisation** : un seul endroit pour tous les secrets.
+- **Rotation** : changer les clés régulièrement, sans casser les apps.
+- **Audit** : qui a accédé à quoi, quand.
+- **Least privilege** : chaque app/service n'a accès qu'à ses propres secrets.
+
+## Cas d'Usage
+- Applications cloud (clés AWS, tokens DB).
+- CI/CD (tokens pour publier des artefacts).
+- Kubernetes (secrets distribués aux pods).
+
+## Outils Liés
+- **HashiCorp Vault** (référence).
+- **Bitnami Sealed Secrets** (K8s).
+- **Doppler**, **Infisical** (SaaS/self-host).
+- **SOPS** (Mozilla, chiffrement de fichiers YAML/JSON).
+
+## Pages Liées
+- [[zero-trust]]
+- [[securisation-home-lab]]
+- [[checklist-mise-en-production]]
+
+## Questions Ouvertes
+- Vault est-il trop complexe pour une petite équipe ?
+- Comment gérer les secrets en développement local ?
+
+## Liens
+- [[cles-ssh]]
+- [[rotation-secrets]]

concepts/securisation-home-lab.md

@@ -0,0 +1,26 @@
+---
+title: Sécurisation Home-Lab
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [auto-hébergement, security, networking]
+sources: [raw/articles/securisation-home-lab.md]
+confidence: high
+contested: false
+---
+# 🛡️ Sécurisation Home-Lab
+
+La sécurisation d'un home-lab est critique dès l'ouverture de ports vers l'internet public. Elle repose sur la défense en profondeur.
+
+## Composants de Sécurité
+- **Reverse Proxy** : Point d'entrée unique. [[traefik]] et Nginx Proxy Manager sont les standards.
+- **Isolation** : Utilisation des **User Namespaces** dans Docker pour empêcher l'escalade de privilèges.
+- **Intrusion Detection** : [[crowdsec]] (collaboratif) ou Fail2ban (local).
+
+## Liens
+- [[traefik]]
+- [[fail2ban]]
+- [[crowdsec]]
+- [[firewall]]
+- [[docker]]
+

concepts/security.md

@@ -0,0 +1,27 @@
+---
+title: Sécurité Informatique
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, tech]
+confidence: medium
+contested: false
+sources: []
+---
+# 🛡️ Sécurité Informatique
+
+Domaine couvrant la **protection des systèmes d'information** contre les menaces (attaques, fuites, pannes).
+
+## Domaines Connexes
+- **Cryptographie** : [[cryptographie-post-quantique]], [[hash-cryptographique]], [[chiffrement-bout-en-bout]].
+- **Réseau** : [[firewall]], [[vpn]], [[zero-trust]].
+- **DevSecOps** : [[attaque-chaine-approvisionnement]], [[secret-management]].
+
+## Pages Liées
+- [[securisation-home-lab]]
+- [[checklist-securite-vps]]
+- [[tls-https]]
+- [[zero-trust]]
+
+## Liens
+- [[cours-pqc]]

concepts/server-side-rendering.md

@@ -0,0 +1,45 @@
+---
+title: Server-Side Rendering (SSR)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, web, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🖥️ Server-Side Rendering (SSR)
+
+## Définition Courte
+Technique de rendu web où le HTML est généré **côté serveur** à chaque requête, puis envoyé complet au navigateur.
+
+## Explication Détaillée
+Opposé au Client-Side Rendering (SPA) où le navigateur reçoit un coquille HTML vide + JS qui fait tout, le SSR envoie une page déjà remplie. Souvent combiné avec **Hydration** : le HTML arrive prêt, puis le JS "prend le relais" pour l'interactivité.
+
+**Avantages** : SEO optimal, First Contentful Paint rapide, pas besoin de JS activé pour voir le contenu.
+**Inconvénients** : charge serveur accrue (rendu à chaque requête), Time to Interactive parfois plus long.
+
+Variantes :
+- **SSG** (Static Site Generation) : HTML généré au build (Next.js export, Hugo, Astro).
+- **ISR** (Incremental Static Regeneration) : regénération à la demande.
+- **Streaming SSR** : envoi par chunks (React Server Components).
+
+## Cas d'Usage
+- Sites avec du contenu public référencé (blog, e-commerce, news).
+- Apps nécessitant un SEO fort.
+- Pages de marketing.
+
+## Outils Liés
+- **Frameworks** : Next.js, Nuxt, SvelteKit, Astro, Remix.
+- **Langages** : Node.js, Go, Rust (via Deno).
+
+## Pages Liées
+- [[concepts-web]]
+- [[architecture-microservices]]
+
+## Questions Ouvertes
+- SSR ou SSG : comment choisir ?
+- Les React Server Components vont-ils rendre le SSR "classique" obsolète ?
+
+## Liens
+- [[stack-frontend-solo-dev]]

concepts/serverless.md

@@ -0,0 +1,44 @@
+---
+title: Serverless
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, architecture, cloud]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ☁️ Serverless
+
+## Définition Courte
+Modèle de cloud computing où le fournisseur gère dynamiquement l'allocation des ressources, facturé à l'usage réel (souvent à la milliseconde).
+
+## Explication Détaillée
+"Serverless" ne signifie pas "sans serveur", mais "sans gestion de serveur". Le code (une fonction) est déployé et le cloud le démarre à la demande. Familles :
+- **FaaS** (Function as a Service) : AWS Lambda, GCP Cloud Functions, Azure Functions.
+- **BaaS** (Backend as a Service) : Firebase, Supabase, PocketBase.
+- **Serverless Containers** : AWS Fargate, Google Cloud Run, Fly.io.
+
+**Avantages** : pas de gestion d'infra, scaling automatique à zéro, paiement à l'usage.
+**Inconvénients** : cold starts, vendor lock-in, limites de runtime (timeout, taille), debugging difficile.
+
+## Cas d'Usage
+- APIs à trafic variable.
+- Webhooks et tâches ponctuelles.
+- Glue code entre services.
+
+## Outils Liés
+- **AWS Lambda**, **Cloudflare Workers**, **Vercel Functions**.
+- **Localstack** pour dev local.
+
+## Pages Liées
+- [[edge-computing]]
+- [[patterns-architecture]]
+- [[architecture-microservices]]
+
+## Questions Ouvertes
+- Le serverless est-il rentable pour des charges constantes (warm workloads) ?
+- Comment éviter le vendor lock-in en serverless ?
+
+## Liens
+- [[webassembly]]

concepts/single-page-application.md

@@ -0,0 +1,42 @@
+---
+title: Single Page Application (SPA)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, web, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 📱 Single Page Application (SPA)
+
+## Définition Courte
+Application web où une seule page HTML est chargée initialement, et le contenu est mis à jour dynamiquement via JavaScript sans rechargement complet.
+
+## Explication Détaillée
+Les SPAs utilisent massivement AJAX et des frameworks JS pour reproduire l'expérience d'une application native. Le routing est géré côté client (React Router, Vue Router).
+
+**Avantages** : UX fluide (pas de rechargement), découplage fort frontend/backend, idéal pour les apps complexes (dashboards, SaaS).
+**Inconvénients** : SEO difficile (nécessite pré-rendu ou SSR), temps de chargement initial plus long, consommation mémoire côté navigateur.
+
+## Cas d'Usage
+- Tableaux de bord (Dashboards, Notion, Figma).
+- Applications SaaS complexes.
+- Outils internes.
+
+## Outils Liés
+- **Frameworks** : React, Vue, Angular, Svelte, Solid.
+- **Routing** : React Router, Vue Router, TanStack Router.
+- **State** : Redux, Zustand, Pinia, Jotai.
+
+## Pages Liées
+- [[server-side-rendering]]
+- [[concepts-web]]
+- [[patterns-architecture]]
+
+## Questions Ouvertes
+- Les SPAs sont-ils en train de fusionner avec le SSR (via Next.js, SvelteKit) ?
+- Comment gérer l'analytics dans une SPA sans cookie ?
+
+## Liens
+- [[stack-frontend-solo-dev]]

concepts/sspl.md

@@ -0,0 +1,35 @@
+---
+title: SSPL (Server Side Public License)
+created: 2026-06-06
+updated: 2026-06-06
+type: entity
+tags: [open-source, legal]
+confidence: medium
+contested: false
+sources: []
+---
+# 📜 SSPL (Server Side Public License)
+
+## Définition Courte
+Licence copyleft stricte créée par MongoDB en 2018 : tout service utilisant le logiciel doit publier **toute la stack technique** sous SSPL, rendant l'auto-hébergement commercial impossible.
+
+## Explication Détaillée
+- Réponse de MongoDB face à AWS (Atlas).
+- **Non reconnue** par l'OSI comme open-source.
+- Plus agressive que la GPL car elle vise les SaaS, pas seulement le code dérivé.
+- Adoptée aussi par Elastic Search, CockroachDB (en alternative à la BSL).
+
+## Cas d'Usage
+- Bases de données critiques (MongoDB, Elasticsearch).
+- Éditeurs voulant empêcher le "cloud-washing".
+
+## Outils Liés
+- [[gpl-v3]] (licence copyleft classique).
+- [[bsl]] (alternative plus modérée).
+
+## Pages Liées
+- [[licences-open-source]]
+- [[monetisation-open-source]]
+
+## Liens
+- [[veille-licences]]

concepts/stack-ia-maison.md

@@ -0,0 +1,27 @@
+---
+title: Stack IA Maison
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [auto-hébergement, IA, docker]
+sources: [raw/articles//stack-docker-ia.md]
+confidence: high
+contested: false
+---
+# 🏠 Stack IA Maison
+
+La mise en place d'une infrastructure d'IA locale repose sur la conteneurisation pour faciliter la gestion des dépendances GPU et des interfaces.
+
+## Composantes Clés
+- **Moteur d'inférence** : [[ollama]], qui gère le chargement des modèles et l'accélération matérielle.
+- **Interface utilisateur** : **Open WebUI**, offrant une expérience proche de ChatGPT.
+- **Data Pipeline** : Outils de scraping automatique pour alimenter le LLM.
+
+## Déploiement
+Généralement orchestré via un fichier `docker-compose.yml` avec support du `nvidia-container-toolkit`.
+
+## Liens
+- Moteur : [[ollama]]
+- Infrastructure : [[docker]]
+- Domaine : [[auto-hebergement]]
+- [[stack-docker-ia]]

concepts/strategie-backup-321.md

@@ -0,0 +1,29 @@
+---
+title: Stratégie Backup 3-2-1
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [auto-hébergement, security, tech]
+sources: [raw/articles/backup-strat-321.md]
+confidence: high
+contested: false
+---
+# 💾 Stratégie Backup 3-2-1
+
+La règle du **3-2-1** est le standard d'or pour la sauvegarde de données, garantissant qu'aucune panne unique ne puisse effacer toutes les copies.
+
+## Le Principe
+- **3 copies** : Une copie originale et deux sauvegardes.
+- **2 supports** : Utiliser deux supports physiques différents (ex: SSD et NAS).
+- **1 copie hors site** : Une sauvegarde dans le cloud ou sur un site distant.
+
+## Outils Recommandés
+- **[[restic]]** : Idéal pour les volumes Docker grâce à la déduplication.
+- **Duplicati** : Pour la simplicité et le support cloud.
+- **Proxmox Backup Server** : Pour les environnements virtualisés.
+
+## Liens
+- Domaine : [[auto-hebergement]]
+- Sécurité : [[securisation-home-lab]]
+- [[stockage-cloud-solo-dev]]
+- [[backup-strat-321]]

concepts/systeme-de-skills.md

@@ -0,0 +1,22 @@
+---
+title: Système de Skills
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [architecture, agent, automation]
+sources: [raw/articles/hermes-agent-docs.md]
+confidence: high
+contested: false
+---
+# 🧰 Système de Skills
+
+Le système de skills de l'Hermes Agent est une forme de **mémoire procédurale**. Au lieu de compter uniquement sur le contexte immédiat (prompt), l'agent charge des documents de connaissances spécifiques au moment opportun.
+
+## Fonctionnement
+- **Divulgation Progressive** : Pour économiser les tokens, le système charge d'abord la liste des skills, puis le contenu complet d'un skill spécifique uniquement si nécessaire.
+- **Standardisation** : Les skills suivent le standard `agentskills.io`, les rendant portables entre différents agents.
+- **Cycle de vie** : Création $\rightarrow$ Utilisation $\rightarrow$ Patch (amélioration) $\rightarrow$ Validation.
+
+## Liens
+- Implémentation : [[hermes-agent]]
+- Catégorie : [[open-source]]

concepts/tech.md

@@ -0,0 +1,23 @@
+---
+title: Technologie (Catégorie)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, meta]
+confidence: medium
+contested: false
+sources: []
+---
+# 💻 Catégorie Tech
+
+Catégorie **transversale** du wiki regroupant tous les concepts techniques généralistes.
+
+## Sous-Thèmes
+- **Architecture** : [[architecture-microservices]], [[patterns-architecture]].
+- **Web** : [[concepts-web]], [[api-rest]].
+- **DevOps** : [[ci-cd]], [[infrastructure-as-code]].
+
+## Pages Liées
+- [[automatisation-dotfiles]]
+- [[concepts-web]]
+- [[patterns-architecture]]

concepts/tls-https.md

@@ -0,0 +1,23 @@
+---
+title: TLS / HTTPS
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [protocol, security, networking]
+sources: [raw/articles/cours-pqc.md]
+confidence: high
+contested: false
+---
+# 🔒 TLS / HTTPS
+
+Le **TLS** (Transport Layer Security) est le protocole cryptographique qui assure la confidentialité et l'intégrité des données transitant sur le web, visible via le préfixe **HTTPS**.
+
+## Évolution Post-Quantique
+Le TLS est actuellement en phase de migration pour intégrer les standards PQC afin de contrer la menace des ordinateurs quantiques. 
+- **Algorithme cible** : [[ml-kem]] (anciennement Kyber) est utilisé pour sécuriser les "handshakes" (poignées de main) entre navigateurs et serveurs.
+- **Déploiement** : Des acteurs comme Cloudflare et des navigateurs (Chrome, Firefox) implémentent déjà ces échanges.
+
+## Liens
+- Technologie de remplacement : [[cryptographie-post-quantique]]
+- Standard associé : [[ml-kem]]
+- [[cours-pqc]]

concepts/tokenisation.md

@@ -0,0 +1,48 @@
+---
+title: Tokenisation
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, ML, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ✂️ Tokenisation
+
+## Définition Courte
+Processus de **découpage d'un texte en unités atomiques** (tokens) que le modèle peut traiter. C'est l'interface entre le langage humain et les embeddings numériques.
+
+## Explication Détaillée
+Un LLM ne lit pas des mots ou des caractères, mais des **tokens** (souvent des morceaux de mots). Les algorithmes les plus courants :
+- **BPE (Byte Pair Encoding)** : utilisé par GPT, Llama, Mistral.
+- **WordPiece** : utilisé par BERT.
+- **SentencePiece** : BPE/ULM au niveau Unicode.
+- **Unigram** : alternative probabiliste.
+
+Exemples :
+- "Bonjour" $\rightarrow$ ["Bon", "jour"] (2 tokens) ou ["Bonjour"] (1 token) selon le modèle.
+- "Intelligence Artificielle" $\rightarrow$ ["Intell", "igence", " Artif", "icielle"].
+
+**Impact concret** : la tarification des API LLM est **au token** (entrée + sortie). Comprendre la tokenisation permet d'optimiser les coûts et de maîtriser la fenêtre de contexte.
+
+## Cas d'Usage
+- Comptage de tokens pour facturation API.
+- Découpage de documents longs pour le RAG (chunking).
+- Calcul de la taille du contexte.
+- Compatibilité inter-modèles (chaque modèle a son tokenizer).
+
+## Outils Liés
+- **tiktoken** (OpenAI).
+- **Hugging Face Tokenizers**.
+- **SentencePiece**.
+
+## Pages Liées
+- [[glossaire-ia]]
+- [[rag]]
+- [[transformer-architecture]]
+- [[embeddings]]
+
+## Questions Ouvertes
+- Pourquoi les modèles ne s'alignent-ils pas sur un tokenizer universel (gain de 10-30%) ?
+- Comment évaluer objectivement la qualité d'un tokenizer ?

concepts/tokenization.md

@@ -0,0 +1,19 @@
+---
+title: Tokenization (Alias)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, ML, tech]
+confidence: medium
+contested: false
+sources: []
+---
+# 🤖 Tokenization (Alias)
+
+Cette page est un alias de [[tokenisation]] (en français).
+
+## Pages Liées
+- [[tokenisation]]
+- [[glossaire-ia]]
+- [[rag]]
+- [[transformer-architecture]]

concepts/transformer-architecture.md

@@ -0,0 +1,52 @@
+---
+title: Architecture Transformer
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [IA, architecture, model]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🤖 Architecture Transformer
+
+## Définition Courte
+Architecture de réseau de neurones introduite par Google en 2017 ("Attention Is All You Need") qui repose entièrement sur le mécanisme d'**attention** pour modéliser les relations dans les données séquentielles. C'est la base de TOUS les LLM modernes.
+
+## Explication Détaillée
+Le Transformer a remplacé les RNN/LSTM grâce à deux innovations :
+- **Self-Attention** : chaque token "regarde" tous les autres tokens de la séquence en parallèle, calculant une importance relative. Permet de comprendre le contexte global.
+- **Parallélisation totale** : contrairement aux RNN (séquentiels), tout est calculé en parallèle $\rightarrow$ GPU-friendly, entraînement rapide.
+
+Composants :
+- **Embeddings** : token + positionnel.
+- **Encoder** : traite l'entrée (utilisé par BERT, RoBERTa).
+- **Decoder** : génère la sortie (utilisé par GPT, Llama, Mistral).
+- **Multi-Head Attention** : plusieurs mécanismes d'attention en parallèle.
+- **Feed-Forward Layers** : couches denses entre les attentions.
+- **LayerNorm + Residual Connections** : stabilité de l'entraînement.
+
+Variantes importantes :
+- **Encoder-only** (BERT) : compréhension.
+- **Decoder-only** (GPT, Llama) : génération. C'est ce qu'on appelle communément "LLM".
+- **Encoder-Decoder** (T5, BART) : traduction, summarization.
+
+## Cas d'Usage
+- Tous les LLM modernes (GPT, Claude, Llama, Mistral, Phi).
+- Traduction automatique.
+- Génération de code.
+- Vision (ViT) et audio (Whisper) adaptés.
+
+## Outils Liés
+- Implémentations de référence : PyTorch, JAX/TF.
+- Bibliothèques : Hugging Face Transformers, llama.cpp (cf. [[llama-cpp]]).
+
+## Pages Liées
+- [[llama-3-1]], [[mistral]], [[phi-3-5]]
+- [[mixture-of-experts]]
+- [[tokenization]]
+- [[glossaire-ia]]
+
+## Questions Ouvertes
+- Le Transformer va-t-il être remplacé par une nouvelle architecture (Mamba, RWKV) ?
+- Combien de temps l'attention quadratique O(n²) reste-t-elle viable à très long contexte ?

concepts/vpn.md

@@ -0,0 +1,47 @@
+---
+title: VPN (Virtual Private Network)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, networking, tech]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🌐 VPN (Virtual Private Network)
+
+## Définition Courte
+Technologie créant un **tunnel chiffré** entre deux points (votre machine et un serveur distant) pour assurer confidentialité et intégrité des échanges.
+
+## Explication Détaillée
+Un VPN encapsule le trafic dans un protocole chiffré. Protocoles modernes :
+- **WireGuard** : rapide, simple, basé sur Curve25519.
+- **OpenVPN** : très mature, basé sur SSL/TLS.
+- **IPsec** : standard entreprise, complexe.
+- **Tailscale/WireGuard mesh** : overlay network zero-config.
+
+## Cas d'Usage
+- Accès distant sécurisé à un réseau d'entreprise.
+- Auto-hébergement : accéder à son lab depuis l'extérieur.
+- Contournement de restrictions géographiques.
+- Protection sur Wi-Fi public.
+
+## Outils Liés
+- **WireGuard** (kernel ou userspace).
+- **Tailscale**, **Headscale** (serveur open-source de Tailscale).
+- **OpenVPN**, **Pivpn** (Pi-hole + WireGuard).
+- **Cloudflare Tunnel** (VPN-as-a-service).
+
+## Pages Liées
+- [[glossaire-homelab]]
+- [[zero-trust]]
+- [[tls-https]]
+- [[openssh]]
+
+## Questions Ouvertes
+- WireGuard va-t-il totalement remplacer OpenVPN ?
+- Le VPN est-il encore pertinent face à Zero Trust Network Access (ZTNA) ?
+
+## Liens
+- [[cles-ssh]]
+- [[reseau-decentralise]]

concepts/webassembly.md

@@ -0,0 +1,45 @@
+---
+title: WebAssembly (WASM)
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, web, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🕸️ WebAssembly (WASM)
+
+## Définition Courte
+Format binaire d'instructions pour une **machine virtuelle basée sur une pile**, conçu comme cible de compilation portable pour des langages haut niveau (C++, Rust, Go, etc.).
+
+## Explication Détaillée
+WASM permet d'exécuter du code quasi-natif (proche du C++ en performance) dans :
+- **Navigateurs** : à côté de JavaScript.
+- **Edge** : Cloudflare Workers, Fastly.
+- **Plugins** : extensions sécurisées (Envoy WASM filters).
+- **Server-side** : Wasmtime, Wasmer.
+
+**Avantages** : performance, sécurité (sandbox strict par défaut), polyglotte, portable.
+**Inconvénients** : écosystème immature hors navigateur, debugging limité.
+
+## Cas d'Usage
+- Calcul intensif côté navigateur (Figma, Photoshop Web).
+- Remplacement de Docker dans certains cas (WASM containers, ex: Spin de Fermyon).
+- Plugins sandboxés (Istio/Envoy).
+- Edge functions ultra-rapides.
+
+## Outils Liés
+- **Wasmtime**, **Wasmer** (runtimes).
+- **Spin** (Fermyon, serverless WASM).
+- **Emscripten** (compile C/C++ vers WASM).
+- **AssemblyScript** (TS-like pour WASM).
+
+## Pages Liées
+- [[edge-computing]]
+- [[serverless]]
+- [[concepts-web]]
+
+## Questions Ouvertes
+- WASM va-t-il remplacer les conteneurs Linux ?
+- Quel est l'avenir de WASI (WebAssembly System Interface) ?

concepts/zero-trust.md

@@ -0,0 +1,42 @@
+---
+title: Zero Trust
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [security, tech, architecture]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# 🚫 Zero Trust
+
+## Définition Courte
+Modèle de sécurité qui part du principe qu'**aucune confiance** ne doit être accordée par défaut, même à l'intérieur du réseau. Chaque accès est vérifié explicitement.
+
+## Explication Détaillée
+Le Zero Trust contredit le modèle traditionnel du "château fort" (périmètre dur + intérieur mou). Les piliers :
+- **Vérification explicite** : auth et authz pour chaque requête, jamais implicite.
+- **Moindre privilège** : accès juste assez (JIT, JEA).
+- **Assume Breach** : on suppose qu'une compromission existe et on l'isole.
+- **Micro-segmentation** : découpage fin du réseau.
+- **Chiffrement end-to-end** : même au sein du réseau interne.
+
+## Cas d'Usage
+- Travail à distance (post-COVID).
+- Fusions d'entreprises avec des SI hétérogènes.
+- Infrastructure cloud multi-comptes.
+
+## Outils Liés
+- **Identity** : Okta, Auth0, Keycloak.
+- **Network** : Tailscale, Cloudflare Access, Twingate, OpenZiti.
+- **Secrets** : HashiCorp Vault, Bitnami Sealed Secrets.
+- **Policy** : Open Policy Agent (OPA).
+
+## Pages Liées
+- [[securisation-home-lab]]
+- [[vpn]]
+- [[cryptographie-post-quantique]]
+
+## Questions Ouvertes
+- Le Zero Trust est-il adapté à une PME ou seulement à de grandes orgs ?
+- Comment concilier UX et vérifications constantes ?