Aller au contenu

ADR-024 — Stack : Python pour l'IA, TypeScript pour le web (pas de migration)
Statut Accepted
Date 26/06/2026 (call archi Denis × Dimitri × Romain)
Décideurs Denis Mludek (CTO), Romain BAZIL, Dimitri Hertz
Origine Synchro archi 26/06 §3
Nature Ratification du statu quo (no-change ADR) — confirme la répartition existante, aucun changement d'archi. Sa valeur : le choix passe d'implicite à ratifié par le CTO, avec des conséquences engageantes (recrutement).

Contexte

Le système est séparé entre un microservice Python pour l’orchestration IA et une application TypeScript pour les interfaces web. Ce choix n’avait pas encore été ratifié formellement. L’ADR tranche entre unification TypeScript et maintien d’une couche Python spécialisée.

Décision

On conserve la répartition actuelle :

Partie IA (agents, orchestration, RAG, NLP)   →  Python (microservice)
Partie web (UI personas, auth, accès Neon)     →  TypeScript

Pas de migration de l'IA vers TypeScript. La partie TS peut continuer d'appeler des API LLM en direct (ex. rédaction de fiche via OpenRouter) sans passer par Python quand c'est trivial.

Rationale

  • Recrutement : un profil AI engineering aura quasi systématiquement fait du Python ; recruter sur ce périmètre est plus simple en Python aujourd'hui (l'AI engineering n'a ~2 ans d'existence, le vivier est majoritairement Python).
  • Séparation des responsabilités : l’interface web peut itérer rapidement sans exposer la logique IA critique aux mêmes compromis.
  • Capacités Python : pour le NLP (pseudonymisation Presidio), le RAG avancé (re-ranking, embeddings, petits modèles), Python reste nettement plus efficace ; en TS il faudrait de toute façon un microservice.
  • Pas de besoin établi pour l’IA en TS : une migration préventive n’apporte pas de valeur démontrée.
  • ML/deep learning futur : se ferait de toute façon à part (autre projet Python, ou format portable ONNX en microservice) → l'orientation actuelle ne ferme pas cette porte.

Conséquences

Ce qui change

  1. Choix ratifié par le CTO, plus seulement implicite : sécurise les arbitrages futurs.
  2. Les prochains recrutements IA seront des profils AI engineering dédiés (Python), pas des doubles casquettes web+IA.
  3. La frontière reste : TS = web + tuyauterie + appels LLM triviaux ; Python = orchestration agentique + RAG + NLP.

Ce qu'il faut faire

  • Prévoir dans l'archi une abstraction provider LLM (switch facile de modèle — souveraineté + résilience), via un wrapper type LangChain (cf. ADR-026).
  • Isoler tout futur besoin NLP/ML lourd dans un microservice Python dédié.

Ce qu'il faut éviter

  • Migrer l'IA en TS pour une unification cosmétique de stack.
  • Recruter des doubles casquettes web+IA en pensant fluidifier — les deux métiers restent distincts.
  • Mettre de la logique IA critique dans la partie vibe-codée (réintroduirait du risque de régression).

Alternatives écartées

  • Stack 100 % TypeScript unifiée : l'argument d'unification (n'importe qui peut lire/intervenir) ne compense pas la perte sur le recrutement IA et les capacités NLP/RAG ; l'écart de libs s'est réduit mais Python garde l'avantage data.
  • Stack 100 % Python (tout le back, y compris web) : rapatrier l'app dashboard actuelle dans Python serait un gros chantier sans valeur, et tuerait la vélocité vibe-code de la partie web.

Verbatims

« On peut se faire un cadeau en faisant un choix qui nous facilite le recrutement. » — Denis

« Tu as besoin de profils IA maîtrisant l'AI engineering. Un profil qui maîtrise l'AI engineering aura fait du Python, c'est quasiment sûr. » — Dimitri

La séparation permet d’allouer les compétences spécialisées à la couche où le risque technique est le plus élevé.

Voir aussi

Sources