L'Open Source de A à Z
Du noyau Linux à l'IA libre

Définition simple

L'open source, c'est un logiciel dont le code source est public : n'importe qui peut le lire, le modifier, le redistribuer — gratuitement et légalement, dans le respect d'une licence.

Mais open source ≠ gratuit. C'est avant tout un modèle de collaboration ouvert, opposé au logiciel propriétaire dont le code est caché (closed source).

Les 4 libertés fondamentales (FSF)

Définies par Richard Stallman et la Free Software Foundation, elles sont la base philosophique du libre :

Free Software (FSF) et Open Source (OSI) recouvrent en pratique les mêmes logiciels, mais avec des accents différents : philosophique pour la FSF, pragmatique pour l'OSI.

Open source vs Free software vs Source-available

50 ans en 12 dates clés

Permissive vs Copyleft — La distinction fondamentale

Le top 7 des licences à connaître Indispensable

Les licences "presque open source" — Attention au piège

Depuis 2018, plusieurs éditeurs ont quitté les licences OSI pour se protéger des hyperscalers (AWS, Azure, GCP) :

• SSPL (MongoDB, Elastic) : oblige à libérer toute l'infra du SaaS qui l'utilise. Non reconnue OSI.
• BUSL (HashiCorp Terraform, Sentry) : non commerciale 4 ans, puis bascule en Apache. Source-available.
• Elastic License v2 : interdit la revente en SaaS. Non OSI.
• Commons Clause : ajout à une licence pour interdire la revente.

Comment choisir une licence pour votre projet

1. Vous voulez le maximum d'adoption ? → MIT ou Apache 2.0
2. Vous voulez protéger les contributions et garder l'esprit libre ? → GPL v3
3. Vous publiez un service web et voulez que les forks SaaS partagent ? → AGPL v3
4. Vous publiez une bibliothèque (lib) utilisable dans du proprio ? → LGPL ou MPL
5. Vous déposez des brevets ? → Apache 2.0 (clause brevets explicite)

Outils utiles : choosealicense.com (par GitHub), tldrlegal.com.

L'open source en chiffres

Les fondations qui structurent l'écosystème

Les hyperscalers et l'open source — Amour-haine

Les géants tech sont à la fois les plus gros contributeurs et les plus gros consommateurs de l'OSS :

• Microsoft : VS Code, TypeScript, .NET Core, Playwright, propriétaire de GitHub et npm
• Google : Kubernetes, Go, Angular, TensorFlow, Chromium, Android (AOSP)
• Meta : React, PyTorch, Llama, Cassandra (origine), GraphQL, Yarn
• Amazon : OpenSearch, Bottlerocket, Firecracker, AWS SDKs
• Apple : Swift, WebKit, LLVM (origine du compilateur Clang)

Ce qui s'est passé en 18 mois CRUCIAL

Fin 2023, l'IA performante était quasi-monopolisée par les API fermées (OpenAI GPT-4, Anthropic Claude, Google Gemini). En avril 2026, l'écart est marginal sur la plupart des benchmarks entre modèles ouverts et fermés.

Trois bascules majeures :

1. Décembre 2024 : DeepSeek-V3 (671B paramètres MoE) atteint GPT-4o pour 1/40ème du coût d'entraînement.
2. 2025 : Qwen (Alibaba), Llama 4 (Meta), Mistral Large 3, Kimi K2 (Moonshot), GLM 4.5 (Zhipu), Reka Flash 3 déferlent. Tous publiés en poids ouverts.
3. Début 2026 : les premiers reasoning models open source (DeepSeek R2, QwQ-Max) rivalisent avec o3 et Claude 3.7 sur les benchmarks de raisonnement.

Les LLMs ouverts à connaître en 2026

^* Licences "open weights" non OSI : libres pour la plupart des usages mais avec restrictions (clause d'usage acceptable, seuil utilisateurs, etc.).

Open weights vs Open source — La nuance qui compte

La plupart des "LLMs open source" diffusent uniquement les poids du modèle (les milliards de paramètres entraînés), pas les données d'entraînement ni le code complet. C'est de l'open weights, pas du vrai open source.

Stack IA open source en 2026 — L'essentiel

Pourquoi c'est un tournant stratégique

• Souveraineté numérique : faire tourner un LLM on-premise / dans son cloud européen, sans envoyer de données chez OpenAI ou Anthropic.
• Contrôle des coûts : au-delà d'un certain volume, l'open source devient drastiquement moins cher que les API.
• Spécialisation : fine-tuning sur ses données métier — impossible avec une API fermée.
• Audit & sécurité : vérifier comment le modèle se comporte, supprimer les biais, contrôler les fuites.
• Conformité (RGPD, AI Act) : beaucoup plus simple avec un modèle qui tourne sur infrastructure maîtrisée.

OS & runtimes

• Linux (kernel) — GPL v2 — 96% des serveurs publics, 100% des supercalculateurs du Top500.
• Distributions : Ubuntu / Debian, RHEL / Rocky / AlmaLinux, Alpine (léger, conteneurs).
• FreeBSD / OpenBSD — BSD — alternatives historiques très sécurisées.

Web & serveurs

• Nginx — BSD-2 — reverse proxy / serveur web le plus utilisé.
• Apache HTTP Server — Apache 2.0 — historique, toujours partout (LAMP).
• Caddy — Apache 2.0 — HTTPS automatique, configuration moderne.
• HAProxy — GPL v2 — load balancer haute performance.
• Traefik — MIT — reverse proxy cloud-native.

Bases de données

• PostgreSQL — PostgreSQL License (proche BSD) — le SGBD relationnel de référence.
• MariaDB — GPL v2 — fork communautaire de MySQL.
• SQLite — Domaine public — embarqué partout (mobiles, navigateurs).
• Redis — passe en SSPL/RSALv2 en 2024 ⇒ fork Valkey (BSD-3) par la Linux Foundation.
• Apache Cassandra — Apache 2.0 — NoSQL décentralisé haute volumétrie.

Conteneurs & cloud-native (CNCF)

• Docker (engine + Containerd) — Apache 2.0.
• Podman — Apache 2.0 — alternative rootless à Docker.
• Kubernetes — Apache 2.0 — orchestrateur standard.
• Helm — Apache 2.0 — package manager pour K8s.
• Prometheus / Grafana / Loki — observabilité (Apache 2.0 / AGPL).
• OpenTelemetry — Apache 2.0 — standard de télémétrie.
• OpenTofu — MPL 2.0 — fork de Terraform.

Langages & runtimes phares

IDE & éditeurs

• VS Code (MIT, build Microsoft propriétaire) / VSCodium (build 100% libre)
• Zed — Apache/AGPL — éditeur Rust ultra-rapide, collaboratif
• Neovim — Apache 2.0 — vim modernisé et extensible
• Helix — MPL 2.0 — éditeur modal en Rust, batteries included
• JetBrains Fleet / IntelliJ Community — Apache 2.0 (éditions communautaires)

Versioning & collaboration

• Git — GPL v2 — le standard absolu, créé par Linus Torvalds en 2005.
• GitHub (propriétaire, Microsoft) / GitLab CE (MIT) / Gitea (MIT) / Forgejo (GPL v3, fork Gitea)
• Codeberg — instance Forgejo associative, alternative européenne à GitHub.

Sécurité & supply chain

• OWASP Dependency-Check / Trivy / Grype — scan de vulnérabilités (CVE).
• Syft — génération de SBOM (Software Bill of Materials).
• Sigstore / Cosign — signature et vérification d'artefacts.
• OSV.dev — base de données de vulnérabilités open source par Google.
• Renovate / Dependabot — mises à jour automatiques de dépendances.

Bureautique & création libres

• LibreOffice — MPL 2.0 — bureautique complète.
• GIMP — GPL v3 — alternative à Photoshop.
• Inkscape — GPL v3 — vectoriel (alternative à Illustrator).
• Krita — GPL v3 — peinture numérique.
• Blender — GPL v2 — 3D, devenu standard en VFX.
• Audacity / Ardour — audio.
• Kdenlive / OpenShot — montage vidéo.

Les principaux modèles

Le problème du maintainer burnout

Beaucoup de briques critiques (OpenSSL, log4j, core-js, curl…) reposent sur quelques mainteneurs bénévoles. C'est le syndrome "random guy in Nebraska" du célèbre xkcd 2347.

Cas emblématiques :

• Heartbleed (2014) — OpenSSL maintenu par 1 personne à temps plein avant la crise.
• Log4Shell (2021) — faille critique sur log4j, projet sous-financé.
• core-js (2023) — utilisé par 70% du web, mainteneur unique en burnout.
• XZ Utils (2024) — mainteneur ultra-isolé, cible parfaite d'attaque sociale.

Mythe vs réalité

Mythe : "il faut être un dev senior pour contribuer à un grand projet OSS".
Réalité : 80% des contributions utiles ne sont pas du code : doc, traduction, signalement de bug, tri des issues, design, animation de communauté.

Comment commencer concrètement Newbie OK

1. Identifiez un projet que vous utilisez déjà. C'est 10x plus motivant que de chercher "un projet pour contribuer".
2. Lisez le CONTRIBUTING.md et le CODE_OF_CONDUCT.md. C'est la règle du jeu.
3. Cherchez les issues étiquetées good first issue, help wanted, documentation.
4. Annoncez votre intention sur l'issue avant de coder. Évite le travail en double.
5. Faites un fork, une branche, une PR. Patience : la review peut prendre des semaines sur un gros projet.
6. Répondez aux feedbacks. 90% des PRs requièrent au moins une itération.

Anatomie d'un bon repo open source

• README.md — pitch + quick start + lien doc
• LICENSE — obligatoire, choisi explicitement
• CONTRIBUTING.md — comment contribuer
• CODE_OF_CONDUCT.md — règles de comportement (souvent Contributor Covenant)
• SECURITY.md — comment signaler une faille (responsible disclosure)
• CHANGELOG.md — historique des versions (Keep a Changelog + SemVer)
• .github/ISSUE_TEMPLATE/ — templates d'issues
• CI/CD verte (tests automatisés sur chaque PR)

Les 7 pièges classiques

1. Mauvaise lecture de licence. Inclure du code GPL dans un produit fermé : risque juridique majeur.
2. Dépendances abandonnées. Une lib non maintenue depuis 2 ans est une dette de sécurité.
3. Vulnérabilités transitoives. Vous dépendez de A qui dépend de B qui dépend de C compromis.
4. Typosquatting / dependency confusion. react-dom vs react-doom — un faux paquet malveillant.
5. Secrets dans Git. Une clé API pushée par erreur reste pour toujours dans l'historique.
6. "Free as in beer" mindset. Pomper sans jamais contribuer ni sponsoriser : non viable à l'échelle de l'industrie.
7. Forks sauvages. Modifier une lib en interne sans réintégrer upstream : maintenance éternelle à vos frais.

10 bonnes pratiques pour une OSS responsable en entreprise

1. Tenir une SBOM à jour (norme SPDX ou CycloneDX).
2. Scanner les vulnérabilités en CI (Trivy, Grype, Snyk).
3. Mettre en place un OSPO (Open Source Program Office) si vous êtes une grande boite.
4. Cartographier les licences de toutes vos dépendances (FOSSA, ScanCode, license-checker).
5. Privilégier les paquets activement maintenus (>1 mainteneur, commits récents).
6. Verrouiller les versions (lockfiles) et signer les artefacts.
7. Sponsoriser les briques critiques que vous utilisez (GitHub Sponsors, OpenCollective).
8. Contribuer en retour (même modestement : doc, bug reports).
9. Préférer les builds reproductibles.
10. Anticiper le EU Cyber Resilience Act et l'AI Act.

Cadres réglementaires à connaître

• EU Cyber Resilience Act (CRA) — 2024, applicable dès 2027 : oblige les éditeurs de logiciels (même OSS commercialisé) à assurer sécurité et patches. Exemption pour OSS non-commercial.
• EU AI Act — 2024 : niveaux de risque pour les systèmes IA, exemptions pour les modèles "open source" sous conditions.
• NIS2 — obligations cyber pour secteurs critiques (s'applique aux logiciels open source utilisés).
• Executive Order 14028 (USA) — SBOM obligatoire pour fournisseurs du gouvernement fédéral.

Mois 1-2 — Les fondations Débutant

• Installer une distribution Linux (Ubuntu / Mint / Fedora) en dual-boot ou VM.
• Apprendre les bases du shell (bash) : cd, ls, grep, pipes, redirections.
• Comprendre Git : commit, branch, merge, rebase, pull request.
• Lire les 4 libertés FSF + définition OSI + 3 licences (MIT, GPL, Apache).

Mois 3-4 — Première contribution Intermédiaire

• Faire un fork d'un projet que vous utilisez. Réparer un bug ou améliorer la doc.
• Comprendre les conventions de commit (Conventional Commits) et SemVer.
• S'abonner à des newsletters : Console, Hacker News, LWN.net, Open Source Watch.
• Suivre 5 mainteneurs sur GitHub. Lire leurs PRs.

Mois 5-6 — Aller plus loin Avancé

• Publier votre propre paquet (npm, PyPI, crates.io) avec licence claire et CI.
• Contribuer à un projet de fondation (CNCF, Apache, Linux Foundation).
• Faire tourner un LLM open source en local (Ollama + Open WebUI) — comprendre quantization, GGUF.
• Se former sur SBOM, signature d'artefacts, supply chain security.

Ressources référence

• opensource.guide — les guides officiels GitHub (FR dispo).
• choosealicense.com — pour choisir vite.
• OSI — Open Source Definition
• LWN.net — référence des news kernel et OSS.
• Hugging Face — le GitHub de l'IA ouverte.
• Awesome lists — index communautaires par thème.