Comment nos systèmes sont construits.

Ce avec quoi nous travaillons

Les briques en service aujourd’hui

Systèmes : Debian sur le serveur de la maison, Arch sur le poste de travail, qui a aussi servi de banc d’essai aux miroirs WordPress, un serveur virtuel Scaleway pour le portail client, l’hébergement mutualisé des clients chez OVH et HostSilo. Le réseau privé entre machines est Tailscale ; le crawl sort par un espace réseau WireGuard séparé ; Caddy sert de porte d’entrée avec ses certificats automatiques ; Samba partage les fichiers vers un NAS.

Exécution : Docker Compose pour les miroirs WordPress de préproduction, les bases et les applications clientes, une trentaine de conteneurs en service ; systemd pour les services et minuteries de la maison, vingt-six unités pour le moteur seul ; cron pour les rails planifiés.

Langages : Python 3.13 pour le moteur, les pipelines et les applications ; PHP 8.4 pour huit extensions WordPress maison et un module PrestaShop ; Node 22 avec TypeScript, Vite et Preact pour les interfaces qui en ont besoin ; Go pour un outil réseau ; Bash pour la colle.

Données : SQLite quand une base par client suffit ; PostgreSQL 16 quand il faut plus, y compris pgvector pour la recherche par similarité ; MariaDB derrière WordPress ; Valkey comme cache ; des journaux JSON en ajout seul pour les faits.

Documents et images : OCR Tesseract et lecture par modèle de vision pour les factures photographiées, pypdf pour lire les PDF, ReportLab et WeasyPrint pour en produire, Pillow pour les images, Playwright et Chromium pour piloter un navigateur dans nos relevés, prendre les captures et jouer les tests de bout en bout, ffmpeg et MediaPipe pour la vidéo.

Intégrations : Telegram comme canal opérateur, courrier par SMTP et IMAP, API Search Console et PageSpeed de Google, DataForSEO, API REST de WordPress, dépôt par FTPS et SFTP chez les hébergeurs. Modèles : OpenAI, Anthropic, Google et Perplexity par leurs API et leurs outils officiels, avec un bac à sable bubblewrap pour le texte non fiable.

Sauvegardes : état interne et copie hors site par des outils dédiés, instantané avant chaque changement, base PostgreSQL vidée chaque nuit sur le NAS avec trente jours de rétention, copies horodatées des bases SQLite, et un exercice de restauration planifié chaque trimestre.

Déterministe ou confié au modèle

Ce qui est vérifié sans aucun modèle

Dans le pipeline éditorial, treize contrôles sont du code pur, sans appel à un modèle : liens internes, balisage, données structurées, méta-données, intégrité et couverture des citations, affirmations datées, empreinte de voix, fluidité de lecture, position taxonomique, certification avant publication, vérification des résultats enrichis, score final. Un modèle n’intervient que là où le jugement est nécessaire : rédaction, polissage, contrôle des faits, relecture éditoriale.

Le seuil est écrit : une note sous 60 rejette, entre 60 et 75 renvoie en révision, au-dessus de 75 passe. Un défaut de sévérité « erreur » rejette quelle que soit la note. Un contrôle des faits en échec dur bloque la publication sur tous les chemins. Un texte dans une langue non prévue, ou un scanner de langue qui échoue, met l’article en attente d’un humain au lieu de le laisser passer.

Les tirets cadratins, marque d’un texte écrit à la machine, sont retirés par une réécriture déterministe avant tout contrôle, et un moteur éditorial qui en renvoie un provoque une erreur.

Quand ça casse

Ce qui est prévu avant que ça arrive

Les appels aux modèles suivent un ordre écrit : l’outil OpenAI en premier, l’outil Anthropic en second, les API payantes en dernier. Les API payantes sont fermées par défaut : une clé stockée ne suffit pas, il faut un interrupteur explicite pour qu’elles servent. Après trois échecs consécutifs des deux premiers, ils sont écartés dix minutes. Un appel a un délai maximal (cinq minutes par l’outil, deux par l’API) et un budget mensuel : alerte à 80 %, refus à 100 %.

Une réponse qui n’est pas du JSON valide est traitée comme une absence de réponse, à chaque endroit où une réponse est lue. Un état corrompu sur disque est traité comme un état vide. Le texte fourni par un tiers (un client, un site) est lu dans un bac à sable isolé, avec un délai coupé de l’extérieur, par un bras de modèle séparé qui n’a pas le droit d’utiliser d’outils.

Deux exécutions ne peuvent pas se marcher dessus : un verrou par client, en base, avec délai. Les journaux sont en ajout seul et les files mises à jour par remplacement atomique, donc un travail relancé après une coupure ne compte rien deux fois. Ce qui échoue est écrit dans un journal des échecs par client ; un article bloqué par un contrôle est matérialisé dans un dossier « à relire » au lieu de disparaître.

Observer

Savoir ce qui s’est passé

Chaque client a ses journaux : exécutions planifiées, approbations, retraits, échecs, événements. Les secrets y sont caviardés avant écriture. Un tableau de bord opérateur, relancé automatiquement s’il tombe, expose la santé, les incidents, les coûts et l’activité.

Des rails de surveillance tournent à intervalles connus : battement de cœur chaque minute, contrôle de santé toutes les quinze minutes, veille de publication toutes les cinq minutes, veille des créneaux manqués, veille des relectures dues chaque semaine, synchronisation de l’index publié chaque nuit.

Le paquet de passation

Si nous disparaissons demain

Le dépôt commence par un document d’entrée, un document d’architecture, un lexique, et 205 décisions d’architecture datées, chacune expliquant ce qui a été choisi et pourquoi. Les procédures et les rapports de session sont au même endroit. Un développeur qui reçoit le dépôt et les secrets a de quoi faire tourner le système sans nous appeler.

Côté client, le cadrage produit un document de périmètre qui vous appartient, et la mission se termine par un inventaire de sortie : données, règles, documentation, accès. Les modalités de support et de maintenance disent ce qui est suivi dans le temps : dépendances, accès, flux de données, règles de métier, transférabilité.