Construisez des systèmes qui raisonnent — et qui s'exécutent.

L'IA est un problème d'architecture système

L'IA devient précieuse lorsqu'elle peut fonctionner avec de vraies données, de vraies applications, une vraie infrastructure et de vraies contraintes. Le modèle n'est qu'un composant. La partie difficile consiste à concevoir tout ce qui l'entoure pour que le système complet se comporte de manière fiable.

Mon travail se concentre sur cette architecture : comment les modèles accèdent à la connaissance, récupèrent des preuves, utilisent des outils, interagissent avec les logiciels, échangent des données et s'intègrent dans des systèmes réellement exploitables en production.

Cela implique de travailler sur l'architecture IA, la logique applicative, les API, les bases de données, les plateformes full-stack, l'infrastructure, le déploiement et l'exploitation, plutôt que de traiter l'IA comme une fonctionnalité isolée.

Axes techniques actuels

Mon travail actuel se concentre sur la couche entre la capacité du modèle et le comportement fiable du système : décider quand un modèle peut utiliser ses propres connaissances, quand il doit récupérer des informations externes, quelles preuves sont suffisantes, comment les agents doivent exécuter des actions et où les frontières du système doivent être appliquées.

• Génération augmentée par récupération et déclencheurs de récupération
• Systèmes d'agents, utilisation d'outils et boucles d'exécution
• Frontières de contexte, preuves et fiabilité des réponses
• Routage de modèles et architectures sensibles aux capacités
• Infrastructure IA privée, locale et auto-hébergée
• Intégration de l'IA dans les flux applicatifs et de données réels

Architecture des systèmes d'IA

Les applications d'IA modernes ne sont pas construites à partir d'un modèle de langage seul. Les systèmes fiables nécessitent des décisions sur la connaissance, la récupération, le contexte, les outils, l'état applicatif, la validation, la sélection de modèle et la gestion des défaillances.

• RAG et intégration de connaissances externes
• Décisions de récupération et sélection de preuves
• Agents IA et flux de travail basés sur des outils
• Architectures de modèles locaux et distants
• Routage de modèles et de capacités
• Conception du contexte et gestion des frontières de contexte
• Sorties structurées et intégration d'API
• Validation, observabilité et gestion des défaillances

La question architecturale centrale n'est donc pas simplement quel modèle utiliser. C'est ce que le modèle sait, ce qu'il ne sait pas, ce qu'il doit récupérer, quels outils il peut utiliser, quelles preuves sont suffisantes et quand le système doit cesser de faire confiance à une réponse générée.

Architecture de plateforme

L'IA est une couche d'un système logiciel plus vaste. Je conçois des plateformes autour de frontières applicatives claires, de services réutilisables, de modèles de données structurés et d'une architecture orientée production, plutôt que de fonctionnalités isolées.

• Architectures cloud-native et auto-hébergées
• Plateformes multi-locataires et multi-instances
• Services backend et architecture d'API
• PostgreSQL et modélisation des données applicatives
• Authentification, autorisation et accès basé sur les rôles
• Systèmes multilingues et internationalisés
• Plateformes de contenu headless et de publication structurée
• Services d'IA intégrés à la logique applicative existante

Ingénierie de systèmes full-stack

L'architecture compte surtout lorsqu'elle survit à la mise en œuvre. Je travaille sur le frontend, le backend, les données et l'infrastructure afin que les décisions architecturales restent cohérentes depuis l'interface utilisateur jusqu'à la base de données, l'environnement d'exécution et la couche de déploiement.

Les systèmes typiques combinent des frontends Nuxt et Vue, des services Node.js et TypeScript, des couches de données PostgreSQL et Prisma, Python lorsqu'il offre le meilleur compromis technique, et une infrastructure de production basée sur Linux.

Ingénierie de production

Un prototype démontre une idée. Un système de production doit survivre au déploiement, aux données réelles, à l'évolution des exigences, au comportement des utilisateurs, au trafic, aux mises à niveau, aux défaillances et au développement continu.

• Environnements de serveurs Linux
• NGINX et routage applicatif
• Déploiement d'applications et exploitation en runtime
• Migrations de bases de données et cycle de vie des données
• Workflows de build et de release
• Journalisation, diagnostics et surveillance technique
• Performance, explorabilité et contraintes de diffusion
• Intégration de runtimes IA locaux et hébergés

Systèmes construits en pratique

L'architecture décrite ici n'est pas théorique. Elle est développée à travers des systèmes que je conçois, construis, exploite et étends en continu.

Client IA Aaasaasa

Une application IA de bureau construite autour d'Electron et TypeScript avec prise en charge de modèles locaux et distants, abstraction des fournisseurs, frontières applicatives sécurisées et intégration avec des runtimes IA externes.

Aaasaasa Entreprise

Une architecture de plateforme orientée entreprise combinant services applicatifs, données structurées, accès basé sur les rôles, contenu multilingue, capacités IA et fonctionnalités métier modulaires.

Plateforme stajic.de

Une plateforme de production utilisée pour la publication structurée, la diffusion multilingue, les workflows assistés par IA, la recherche technique et des expérimentations autour de la recherche, de la récupération et de la connaissance lisible par IA.

Plateformes de production indépendantes

loving.rocks, figure.rocks et les systèmes associés étendent la même approche d'ingénierie à des environnements de production indépendants avec leurs propres audiences, modèles de contenu, structures multilingues, exigences de recherche et contraintes opérationnelles.

Recherche technique et rédaction

Une part importante de mon travail actuel examine la frontière entre la capacité des modèles de langage et le comportement fiable des applications. L'objectif est de transformer une architecture IA complexe en concepts qui peuvent être expliqués, testés, remis en question et implémentés.

• Comment le RAG connecte les modèles à des connaissances externes
• Où un LLM obtient ses informations et où commence la récupération
• Quand un système IA devrait cesser de s'appuyer sur les connaissances du modèle
• Comment les preuves doivent être sélectionnées et validées
• Pourquoi des fenêtres de contexte plus grandes ne produisent pas automatiquement de meilleures réponses
• En quoi les boucles d'agents diffèrent de l'infrastructure d'agents gérée
• Comment une architecture IA privée modifie les décisions d'infrastructure
• Où la fiabilité des réponses se dégrade entre la récupération et la génération

Ces sujets forment une base de connaissances techniques connectée plutôt qu'une collection d'articles isolés. Chacun aborde une frontière différente au sein des systèmes IA modernes.

Un système, pas une collection de fonctionnalités

Le frontend, le backend, l'IA, les données et l'infrastructure sont souvent discutés comme des disciplines séparées. En production, ils s'affectent continuellement les uns les autres.

Une décision de récupération modifie l'architecture des données. L'architecture des données affecte les API. Les API affectent l'état de l'application. L'état de l'application affecte le comportement de l'agent. L'infrastructure limite les choix de modèles. L'architecture de recherche affecte la façon dont l'information est découverte par les personnes et les machines.

Mon approche est donc orientée système : comprendre la chaîne complète avant d'optimiser un composant individuel.

Fondation technique

• TypeScript et JavaScript
• Nuxt et Vue
• Node.js et Nitro
• Python
• PostgreSQL et Prisma
• REST et API applicatives
• Electron
• Linux et NGINX
• Docker et déploiement basé sur les services
• API OpenAI et outillage d'agents
• Environnements d'exécution LLM locaux, y compris Ollama
• Contenu structuré et EditorJS

L'architecture doit aussi être livrable

L'architecture technique existe à l'intérieur des produits, des projets, des budgets, des dépendances et des délais. Mon travail combine donc l'ingénierie avec une livraison structurée plutôt que de séparer les décisions techniques de la responsabilité de mise en œuvre.

Plus de deux décennies de travail pratique en informatique sont complétées par des méthodes formelles de projet et de livraison, notamment la certification IPMA et Professional Scrum Master. Ces méthodes soutiennent le travail d'ingénierie ; elles ne le remplacent pas.

Construire quelque chose qui peut réellement fonctionner

L'objectif n'est pas d'attacher l'IA à tout. Il est d'identifier où l'IA apporte une réelle capacité système, de concevoir l'architecture autour d'elle et de construire le logiciel environnant suffisamment solidement pour que cette capacité devienne utile.

De la récupération et du comportement des modèles aux API, aux données, aux interfaces et à l'infrastructure, l'objectif reste le même : des systèmes techniquement cohérents qui passent de l'architecture à la production.