Stack open source

Comment choisir un système open source dans une architecture SI moderne

Chaque décision présente plusieurs options crédibles, avec leurs logiques d’usage, limites, interopérabilités et systèmes représentatifs.

Point de départ

On ne choisit pas un outil par popularité, mais par rôle dans l’architecture et par capacité à tenir l’exploitation dans la durée.

Ordre de lecture conseillé

InterfaceRuntimeOrchestrationRAG / KnowledgeDocumentaireData / AnalyticsQualité / Sécurité / SupervisionDistributionDocumentation / Acculturation

Choisir une interface d’accès à l’IA

Front conversationnel multi-modèles et plus outillé

Logique: front plus riche pour fournisseurs multiples, outils, mémoire, MCP

Forces: polyvalence, profondeur fonctionnelle

Limites: plus de complexité que les UIs minimales

Interopérabilités: MCP, Ollama, fournisseurs multiples, outils

Décision à prendre: Choisir une interface d’accès à l’IA

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: plus de complexité que les UIs minimales

Systèmes publiés reliés

LibreChat

UI dédiée à une app conversationnelle

Logique: exposer une app IA spécifique, pas seulement un front générique

Forces: excellent pour POC, démos, apps ciblées

Limites: moins pertinent comme cockpit transverse universel

Interopérabilités: FastAPI, LangGraph, Dify, notebooks, backends Python

Décision à prendre: Choisir une interface d’accès à l’IA

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: moins pertinent comme cockpit transverse universel

Systèmes publiés reliés

Chainlit Gradio

Copilot embarqué dans une application

Logique: intégrer l’IA directement dans une interface produit ou métier

Forces: cohérence UX avec l’application hôte

Limites: demande plus de développement applicatif

Interopérabilités: React, agents, LLM, backends web

Décision à prendre: Choisir une interface d’accès à l’IA

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: demande plus de développement applicatif

Systèmes publiés reliés

CopilotKit

Choisir un runtime ou moteur d’exécution de modèles

Compatibilité OpenAI locale multi-modèles

Logique: servir localement plusieurs modèles derrière une API homogène

Forces: souplesse d’intégration

Limites: moins standard de fait qu’Ollama dans certains contextes

Interopérabilités: clients OpenAI-compatibles, services internes

Décision à prendre: Choisir un runtime ou moteur d’exécution de modèles

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: moins standard de fait qu’Ollama dans certains contextes

Systèmes publiés reliés

LocalAI

Moteur local bas niveau / embarqué

Logique: contrôle fin et exécution sur environnements variés

Forces: performance locale, edge, variété de cibles

Limites: plus technique, moins prêt à l’emploi pour des équipes larges

Interopérabilités: UIs locales, runtimes, edge workflows

Décision à prendre: Choisir un runtime ou moteur d’exécution de modèles

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: plus technique, moins prêt à l’emploi pour des équipes larges

Systèmes publiés reliés

llama.cpp MLC LLM

Serving plus industrialisé

Logique: servir des modèles à plus grande échelle

Forces: efficacité, mutualisation, meilleure logique plateforme

Limites: charge d’infrastructure plus forte

Interopérabilités: APIs OpenAI-like, Kubernetes, observabilité LLM

Décision à prendre: Choisir un runtime ou moteur d’exécution de modèles

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: charge d’infrastructure plus forte

Systèmes publiés reliés

vLLM Text Generation Inference

Choisir une orchestration IA / agents

Framework agentique code-first

Logique: construire finement des agents et workflows en code

Forces: contrôle, extensibilité, structuration

Limites: complexité supérieure, besoin de doctrine

Interopérabilités: LiteLLM, MCP, RAG, observabilité, FastAPI

Décision à prendre: Choisir une orchestration IA / agents

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: complexité supérieure, besoin de doctrine

Systèmes publiés reliés

LangGraph AutoGen CrewAI Semantic Kernel PydanticAI

Workflow / automation transverse

Logique: orchestrer tâches, services, automatisations et exécutions robustes

Forces: très bon pour industrialiser des flux

Limites: n’est pas toujours un vrai framework agentique

Interopérabilités: APIs, services internes, assistants, pipelines data

Décision à prendre: Choisir une orchestration IA / agents

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: n’est pas toujours un vrai framework agentique

Systèmes publiés reliés

n8n Prefect Temporal

Couche mémoire et contexte

Logique: enrichir les agents d’une mémoire long terme

Forces: personnalisation et continuité

Limites: risque de complexité comportementale

Interopérabilités: agents, assistants, profils utilisateurs

Décision à prendre: Choisir une orchestration IA / agents

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: risque de complexité comportementale

Systèmes publiés reliés

mem0

Choisir une stratégie RAG / knowledge

Framework de retrieval / indexing

Logique: construire la logique RAG à un niveau plus maîtrisé

Forces: contrôle, extensibilité, meilleure intégration produit

Limites: effort d’ingénierie plus important

Interopérabilités: Qdrant, Weaviate, Chroma, LangGraph, FastAPI

Décision à prendre: Choisir une stratégie RAG / knowledge

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: effort d’ingénierie plus important

Systèmes publiés reliés

LlamaIndex Haystack Embedchain

Moteur de search textuel

Logique: privilégier recherche texte, search classique ou meta-search

Forces: lisibilité et performance sur certains usages

Limites: ne remplace pas toujours une logique vectorielle

Interopérabilités: front web, assistants, observabilité, catalogues

Décision à prendre: Choisir une stratégie RAG / knowledge

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: ne remplace pas toujours une logique vectorielle

Systèmes publiés reliés

Meilisearch Typesense OpenSearch SearXNG

PKM / knowledge personnelle ou d’équipe

Logique: organiser la connaissance avant ou à côté du RAG

Forces: meilleure structuration humaine

Limites: tous ne sont pas de vrais moteurs de retrieval

Interopérabilités: markdown, docs, notes, RAG, équipes

Décision à prendre: Choisir une stratégie RAG / knowledge

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: tous ne sont pas de vrais moteurs de retrieval

Systèmes publiés reliés

ObsidianRAG Logseq Blinko Outline AppFlowy

Choisir une base vectorielle ou un stockage retrieval

Base légère / prototype / embarquée

Logique: accélérer les prototypes et usages légers

Forces: simplicité, adoption en POC

Limites: moins “socle transverse” que d’autres options

Interopérabilités: Python, notebooks, assistants documentaires

Décision à prendre: Choisir une base vectorielle ou un stockage retrieval

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: moins “socle transverse” que d’autres options

Systèmes publiés reliés

Chroma

Choisir une chaîne de traitement documentaire

OCR robuste

Logique: extraire texte de scans, images, PDF complexes

Forces: indispensable sur corpus non nativement textuels

Limites: qualité très variable selon la source

Interopérabilités: Docling, Marker, RAG, ETL

Décision à prendre: Choisir une chaîne de traitement documentaire

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: qualité très variable selon la source

Systèmes publiés reliés

PaddleOCR tesseract.js

Extraction PDF ciblée

Logique: extraire précisément du PDF quand il est déjà exploitable

Forces: simple et efficace sur certains corpus

Limites: pas suffisant pour tous les documents complexes

Interopérabilités: pandas, pipelines Python, RAG

Décision à prendre: Choisir une chaîne de traitement documentaire

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: pas suffisant pour tous les documents complexes

Systèmes publiés reliés

pdfplumber

Conversion locale et souveraine

Logique: convertir localement divers formats bureautiques

Forces: logique souveraine, usage simple

Limites: moins un pipeline complet qu’un maillon utile

Interopérabilités: docs bureautiques, traitements locaux, ingestion

Décision à prendre: Choisir une chaîne de traitement documentaire

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: moins un pipeline complet qu’un maillon utile

Systèmes publiés reliés

VERT

Choisir une plateforme data / analytique

Transformation analytique

Logique: transformer la donnée en SQL versionné et gouvernable

Forces: standard moderne

Limites: dépend d’une stratégie data déjà claire

Interopérabilités: Dagster, warehouses, OpenMetadata

Décision à prendre: Choisir une plateforme data / analytique

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: dépend d’une stratégie data déjà claire

Systèmes publiés reliés

dbt-core

Ingestion et connecteurs

Logique: collecter et synchroniser des sources multiples

Forces: accélération forte

Limites: qualité de mapping et gouvernance nécessaires

Interopérabilités: dbt-core, Dagster, Superset, OpenMetadata

Décision à prendre: Choisir une plateforme data / analytique

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: qualité de mapping et gouvernance nécessaires

Systèmes publiés reliés

Airbyte Meltano

BI transverse

Logique: exposer tableaux de bord, exploration ou reporting narratif

Forces: couverture large des cas analytiques

Limites: risque de dispersion des couches de restitution

Interopérabilités: dbt-core, Airbyte, OpenMetadata

Décision à prendre: Choisir une plateforme data / analytique

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: risque de dispersion des couches de restitution

Systèmes publiés reliés

Superset Metabase Evidence

Visualisation avancée et géospatiale

Logique: construire couches visuelles spécialisées

Forces: très puissant pour cockpit, observatoire, géodata

Limites: davantage des briques de composition qu’un socle complet

Interopérabilités: Streamlit, Panel, front JS, Superset, CKAN

Décision à prendre: Choisir une plateforme data / analytique

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: davantage des briques de composition qu’un socle complet

Systèmes publiés reliés

Bokeh ECharts plotly.js Observable Plot kepler.gl deck.gl

Choisir une fabrique d’outils internes

Framework app Python

Logique: transformer scripts, analyses ou modèles en apps

Forces: excellent pour data et IA

Limites: pas toujours le meilleur choix pour des apps métier durables

Interopérabilités: pandas, FastAPI, notebooks, IA

Décision à prendre: Choisir une fabrique d’outils internes

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: pas toujours le meilleur choix pour des apps métier durables

Systèmes publiés reliés

Streamlit Panel Taipy Reflex

Backend et plateforme applicative

Logique: construire ou exposer des services et apps plus structurés

Forces: base solide pour industrialiser

Limites: plus d’ingénierie qu’un low-code

Interopérabilités: front React, ToolJet, Appsmith, Chainlit, auth

Décision à prendre: Choisir une fabrique d’outils internes

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: plus d’ingénierie qu’un low-code

Systèmes publiés reliés

FastAPI Appwrite PocketBase Payload CMS FastHTML

Choisir un socle de déploiement et d’exploitation

Orchestration cloud-native

Logique: monter en échelle et en mutualisation forte

Forces: puissance maximale

Limites: dette d’exploitation très importante

Interopérabilités: vLLM, MLflow, observabilité, CI/CD

Décision à prendre: Choisir un socle de déploiement et d’exploitation

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: dette d’exploitation très importante

Systèmes publiés reliés

Kubernetes Kubeflow

Sauvegarde et partage

Logique: fiabiliser la disponibilité et la circulation des artefacts

Forces: très utiles, peu visibles, souvent indispensables

Limites: à articuler avec politiques de sécurité et rétention

Interopérabilités: postes, services, équipes

Décision à prendre: Choisir un socle de déploiement et d’exploitation

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: à articuler avec politiques de sécurité et rétention

Systèmes publiés reliés

Restic Copyparty

Choisir une couche qualité, sécurité, supervision

Guardrails et sécurité IA

Logique: contrôler entrées, sorties, comportements et évaluations

Forces: donne une gouvernance de qualité plus explicite

Limites: ne remplace pas le design produit ni la supervision humaine

Interopérabilités: assistants, agents, observabilité, CI

Décision à prendre: Choisir une couche qualité, sécurité, supervision

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: ne remplace pas le design produit ni la supervision humaine

Systèmes publiés reliés

Guardrails NeMo Guardrails Rebuff Promptfoo

Sécurité logicielle et supply chain

Logique: sécuriser code, secrets, images, dépendances, IaC

Forces: brique fondamentale de confiance logicielle

Limites: bruit si trop d’outils sont empilés sans doctrine

Interopérabilités: GitHub, CI/CD, Docker, Kubernetes

Décision à prendre: Choisir une couche qualité, sécurité, supervision

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: bruit si trop d’outils sont empilés sans doctrine

Systèmes publiés reliés

CodeQL Gitleaks Grype Snyk CLI Trivy

Supervision simple et posture

Logique: surveiller disponibilité, posture, inventaire et exposition

Forces: donne une vision opérationnelle concrète

Limites: couvrir trop large avec trop de petits outils peut nuire à la lisibilité

Interopérabilités: serveurs, services, postes, web, cloud

Décision à prendre: Choisir une couche qualité, sécurité, supervision

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: couvrir trop large avec trop de petits outils peut nuire à la lisibilité

Systèmes publiés reliés

Uptime Kuma Beszel Glances ctop Prowler osquery

Choisir une couche réseau / distribution

Alternative overlay distribuée

Logique: overlay réseau robuste et plus historique

Forces: bonne alternative selon les contextes

Limites: arbitrage d’usage à clarifier face à Tailscale

Interopérabilités: machines, sites, services

Décision à prendre: Choisir une couche réseau / distribution

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: arbitrage d’usage à clarifier face à Tailscale

Systèmes publiés reliés

ZeroTierOne

Synchronisation distribuée

Logique: partage de fichiers sans centralisation cloud

Forces: très cohérent avec logique souveraine

Limites: gouvernance documentaire à poser

Interopérabilités: postes, équipes, knowledge, artefacts

Décision à prendre: Choisir une couche réseau / distribution

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: gouvernance documentaire à poser

Systèmes publiés reliés

Syncthing

Exposition ponctuelle

Logique: exposer vite un service local

Forces: pratique pour tests et démos

Limites: pas un standard d’architecture réseau en soi

Interopérabilités: webhooks, démonstrations, APIs locales

Décision à prendre: Choisir une couche réseau / distribution

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: pas un standard d’architecture réseau en soi

Systèmes publiés reliés

Tunnelto

Choisir une couche documentation / acculturation / veille

Référentiels d’apprentissage et d’aide

Logique: accélérer montée en compétence et décisions de détail

Forces: très utile au quotidien

Limites: pas des briques d’exécution

Interopérabilités: poste de travail, docs, onboarding

Décision à prendre: Choisir une couche documentation / acculturation / veille

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: pas des briques d’exécution

Systèmes publiés reliés

tldr GitHub Skills patterns.dev caniemail

Veille et radar

Logique: garder un panorama de marché et de signaux faibles

Forces: évite l’aveuglement technologique

Limites: doit rester séparé du socle

Interopérabilités: architecture, innovation, prospective

Décision à prendre: Choisir une couche documentation / acculturation / veille

Erreur fréquente: choisir cette option comme standard global sans vérifier le contexte d’exploitation.

Quand ne pas choisir: doit rester séparé du socle

Systèmes publiés reliés

awesome-selfhosted awesome-docker OpenDia Ruflo GooseAI examples Open LLaMA

Piliers connexes

Grandes catégories et capacités SI Topologies d’architecture open source pour IA, data, automation et knowledge DevIAsecOps et pratiques combinées