Portrait technique — Telaria
Ce document s'adresse à qui veut évaluer, pas à qui veut être convaincu. Il décrit un projet réel, ses choix, ses contraintes, et la manière dont chaque couche a été construite. La preuve n'est pas dans ce texte — elle est dans les dépôts.
Ce que Telaria est, et ce qu'il démontre
Telaria est une application web Symfony déployée en production, conçue et pilotée par une seule personne. Ce n'est pas une démonstration de concept ni un projet de formation : c'est un produit, avec ses utilisateurs, son infrastructure, ses contraintes réglementaires et sa roadmap.
Ce qui en fait une vitrine technique n'est pas uniquement ce qu'il contient — c'est comment il a été construit, et surtout avec quoi. Le projet intègre l'intelligence artificielle non pas comme une fonctionnalité ajoutée après coup, mais comme un choix architectural structurant. Et la documentation que vous lisez en ce moment en est la démonstration la plus directe : elle est produite, structurée et maintenue par plusieurs instances Claude coordonnées, avec des specs versionnées, des inboxes de communication asynchrones, une mémoire persistante par dépôt. Ce n'est pas un projet sur l'IA — c'est un projet fait avec l'IA, de bout en bout.
Les fondations : infrastructure, backend, déploiement
Tout commence par une machine : un VPS Ubuntu, une stack Apache, MySQL, PHP 8.4. Rien d'original dans la liste — ce qui compte, c'est la rigueur d'assemblage. Les vhosts sont versionnés dans tlr-vhosts. L'infrastructure est reproductible via Ansible (tlr-ansible) : un provision.yml qui tourne failed=0 sur un laptop Ubuntu fraîchement installé, livrant l'application en HTTP 200 sans intervention manuelle. Ce n'est pas un objectif cosmétique — c'est la réponse concrète à la question « que se passe-t-il si le VPS disparaît demain ? ».
Le backend est construit sur Symfony dans sa forme la plus idiomatique : Doctrine avec entités auto-mappées, Voters pour l'autorisation, messages asynchrones via Messenger, commandes de maintenance et de seeding, configuration par bundle. Le front est porté par Twig et Stimulus — des choix délibérément sobres, qui laissent la qualité d'implémentation comme seul différenciateur, sans framework JavaScript à gouverner. L'architecture a évolué au fil d'un split progressif en bundles réutilisables — tlr-symfony (socle générique multisite), tlr-rag (moteur RAG), tlr-codexia (produit doc-IA) — chacun extrait sans migration de données, sans rupture de déploiement.
La qualité comme contrainte de conception
L'accessibilité RGAA 4.1 niveau AA n'est pas un badge affiché en bas de page : c'est une contrainte qui a influencé le choix des composants, la structure des formulaires, la gestion des contrastes et des alternatives textuelles. Même chose pour le RGPD : les données personnelles ont été cartographiées, la politique de rétention est définie, les formulaires de consentement sont explicites. Ces sujets ne sont pas des obligations à cocher — ce sont des disciplines qui changent la façon de concevoir un formulaire, une API, un email transactionnel.
La démarche qualité Opquast structure la façon d'aborder les bonnes pratiques web : pas comme un audit ponctuel, mais comme un réflexe de conception. Un lien externe s'ouvre avec la signalétique appropriée. Un formulaire a un label explicite. Une page d'erreur est utile. Ces détails forment une posture, pas une liste.
La sécurité comme posture
Les security headers déployés en production — CSP en mode Report-Only progressif, X-Frame-Options DENY, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COEP/COOP/CORP — ne sont pas le résultat d'un scan automatique corrigé en urgence. Ils ont été pensés, testés navigateur, et versionnés dans le rôle Ansible apache-tuning. Le TLS est configuré, les certificats gérés, le pare-feu en place. La signature DKIM des emails transactionnels (multi-NDD, relais OVH) est opérationnelle et documentée.
La sécurité applicative suit la même logique : les tokens d'authentification MCP utilisent SHA-512, le contrat d'interface est figé dans la spec et dans le code, les Voters Symfony encapsulent les règles d'autorisation. Quand une clé API a été committée par erreur, la procédure de remédiation a été documentée et close proprement — trace dans l'historique, pas de balayage sous le tapis.
L'intelligence artificielle comme choix architectural
Le moteur RAG est intégré via tlr-rag, un bundle Symfony consommant un microservice Python d'embeddings (tlr-embeddings) et exposant une interface de chat documentaire. Le serveur MCP (tlr-mcp) expose les documents ingérés à Claude via le protocole Model Context Protocol, avec authentification par token opaque, quotas par tenant et par outil, et trois outils (list_docs, read_doc, search_docs). Ce n'est pas une intégration de démonstration — elle tourne en production.
La veille est agentique : un scheduler déclenche des agents de curation, les résultats sont proposés à validation dans un back-office, les sources sont versionnées et scorées. L'ensemble est conçu pour être auditable : chaque étape est traçable, les décisions de l'IA ne sont pas opaques.
La documentation comme preuve en acte
Ce que vous lisez ici est produit par un écosystème de plusieurs instances Claude coordonnées : une instance pilotant la documentation et les specs (telaria-doc, hémisphère processus), une autre pilotant le code (telaria-app, hémisphère technique), des instances exécutantes sur les bundles. Elles communiquent par inboxes fichiers versionnées, synchronisées via un rituel /sync. Chaque instance a une mémoire persistante, un rôle borné, une définition du terminé et du livré. Les décisions structurantes ne se prennent pas unilatéralement — elles passent par les deux.
Ce n'est pas de la mise en scène. C'est la façon dont ce projet est réellement piloté, quotidiennement, depuis plusieurs mois. L'adoption de l'IA n'est pas une promesse inscrite dans un README — elle est lisible dans l'historique git, dans la structure des dépôts, dans les specs vérifiables dans le code.
C'est ce qu'on entend par démonstration en acte : le projet prouve par sa forme ce qu'il affirme dans son fond.
Voir aussi
pilotage/competences.md— taxonomie des 10 compétences (source de vérité des tags).pilotage/ecosystem.md— topologie de l'écosystème multi-instances.specs/architecture-univers-telaria.md— doc fondateur de l'architecture.