Paradigme

Pensées préalable

Je commence par définir l'attente réelle. Quel est le besoin précis ? Qu'est-ce qui est réellement essentiel ? Une fois cette analyse faite, je construis uniquement ce qui est nécessaire. Rien de plus.

Ce n'est pas du minimalisme esthétique. C'est du minimalisme fonctionnel. Chaque ligne de code possède une raison d'exister. Chaque fonction répond à un besoin identifié. Ce qui ne sert pas n'existe pas.

Homeostasis, dans sa version vide sans projet, pèse 13 Mo. Genesis, système complet de gestion de contenu et génération de site, pèse moins de 1 Mo. Ces chiffres ne sont pas des objectifs en soi. Ils sont la conséquence naturelle d'une approche qui ne construit que l'essentiel.

Économie par essence

Je conçois mes systèmes pour qu'ils consomment le minimum de ressources nécessaires. Pas par contrainte budgétaire. Par logique.

Cette approche a plusieurs dimensions. Écologique : moins de consommation électrique, moins de sollicitation serveur. Économique : hébergement mutualisé plutôt que VPS coûteux. Technique : systèmes plus rapides, plus fiables, plus maintenables.

Genesis génère des sites statiques qui tournent sur n'importe quel hébergement basique. Homeostasis utilise une architecture event-driven où les nœuds restent inactifs jusqu'à sollicitation. Echo fonctionne en polling adaptatif qui réduit la bande passante de 90% sur les conversations inactives.

Ces choix produisent des systèmes légers qui accomplissent leur fonction sans mobiliser plus de ressources que nécessaire. C'est une logique d'efficacité, pas de restriction.

Entre intentionnalité, maîtrise et rejet des automatismes

Je ne mets rien dans mes systèmes que je ne comprends pas. Chaque élément a une raison d'exister que je peux expliquer. Si je ne sais pas pourquoi c'est là, ça n'y est pas.

Cette règle structure toute ma collaboration avec l'IA. Elle produit souvent trop : bonnes pratiques inutiles, CSS redondant, structures complexes. Je lis. J'analyse. Je demande : "À quoi sert ce bout ?" Si la réponse est "bonne pratique" ou "au cas où", on retire. Si c'est "parce que ça fait exactement ce que tu veux", on garde.

Cette compréhension totale me permet de débugger efficacement. Quand quelque chose ne fonctionne pas, je sais où chercher. Pas parce que je lis le code ligne par ligne, mais parce que je comprends la mécanique du système. Je sais ce que chaque partie est censée faire. Quand le résultat ne correspond pas à l'attente, je peux identifier où ça coince.

Paradoxalement, c'est souvent moi qui trouve les bugs. Quand l'IA a la tête dans le code, elle ne voit pas le problème. Je la dirige vers l'erreur, elle corrige.

Équilibre & Cohérence

Je refuse d'intégrer des fonctionnalités simplement parce qu'elles sont populaires ou attendues. Chaque ajout doit avoir du sens dans l'architecture globale.

Genesis n'a pas de drag & drop pour construire les pages. Tous les constructeurs de sites proposent cette fonctionnalité. Je l'ai volontairement exclue. Pourquoi ? Parce que le drag & drop crée des problèmes : responsive cassé, incohérences visuelles, mise en page chaotique. Le système de sections empilables et de blocks paramétrables offre plus de contrôle, plus de cohérence, un meilleur résultat final.

Cette décision est subversive. Ne pas faire quelque chose que tout le monde fait demande plus de courage que de suivre les tendances. Mais si ça va contre la logique du système, je ne le fais pas.

J'améliore mes systèmes régulièrement. J'ajoute des fonctionnalités quand elles manquent vraiment. Mais je n'ajoute jamais de features juste pour la checklist ou parce que c'est cool. Chaque ajout doit renforcer la cohérence, pas la diluer.

Mécanique de l'évènement

Pourquoi faire tourner un système en boucle quand on peut simplement réagir aux événements ?

Genesis n'utilise aucun processus de polling. Homeostasis fonctionne en architecture nodale distribuée, entièrement event-driven. Chaque nœud reste inactif jusqu'à ce qu'un événement le sollicite. Le système utilise un SSE qui s'active lors des interactions front-end, reste actif une seconde, puis s'éteint automatiquement si aucune nouvelle requête n'arrive. Pas de processus long. Pas de consommation continue.

Echo, en tant qu'application de messagerie nécessitant des échanges en temps réel, est la seule de mes créations à utiliser un polling. Mais même dans ce cas, l'implémentation minimise la consommation de ressources avec un polling adaptatif selon l'activité.

Cette approche n'est pas théorique. Elle est appliquée systématiquement parce qu'elle correspond à ma manière de penser : réagir quand nécessaire, rester inactif le reste du temps.

PHP : l'institution

Tous mes systèmes sont construits en PHP. Ce choix surprend souvent. PHP n'est ni moderne, ni à la mode. Mais il correspond exactement à ma manière de penser.

J'ai commencé avec Node.js et Python. Node nécessitait de gérer des serveurs en continu, de prévoir leur redémarrage en cas de plantage, de multiplier les instances pour éviter qu'un problème ne fasse tout tomber. Python posait des problèmes similaires de déploiement.

PHP a été une révélation. Pas de serveur à lancer. Ultra léger. Déployable directement sur un hébergement mutualisé sans passer par un VPS. Le code fonctionne en local, il fonctionnera en ligne. On modifie un fichier, on l'upload via FTP, le changement est immédiat. Pas de compilation. Pas de redémarrage.

PHP est un langage mécanique. Un événement déclenche une action qui déclenche la suivante. Tout est prévisible. Tout est contrôlable. Cette logique séquentielle correspond parfaitement à ma manière de concevoir les systèmes.

Le langage existe depuis des décennies. Il est complet nativement. Besoin d'enregistrer une image ? La fonction existe. Besoin d'utiliser CURL ? C'est intégré. Pas besoin d'installer des dizaines de dépendances. Pas de gestion de versions conflictuelles. Les fonctionnalités sont là, elles fonctionnent, elles sont documentées.

Cette documentation exhaustive est un avantage majeur quand on travaille avec des modèles de langage. Ils connaissent parfaitement PHP. Ils peuvent coder n'importe quelle fonction sans hésitation.

L'include PHP est un autre élément fondamental. Pas besoin de structures complexes pour intégrer du code. On inclut un fichier, il s'exécute. C'est simple, direct, mécanique. Cette simplicité permet de construire des architectures modulaires sans friction.

PHP n'est pas versatile. C'est exactement ce que je recherche. Quand je crée un système, je veux savoir qu'il fonctionnera. Pas de surprises. Pas de comportements imprévisibles. Pas de différences entre environnement de développement et production.

Je n'utilise pas PHP par nostalgie ou par conservatisme. Je l'utilise parce qu'il correspond à ma logique architecturale : mécanique, prévisible, léger, déployable sans friction.

L'ère sémantique

L'arrivée de la recherche intelligente — modèles de langage, agents, chatbots — impose de repenser la structuration de l'information.

Les algorithmes de recherche sémantique ne cherchent pas des mots-clés. Ils cherchent du sens, de la profondeur, une cohérence contextuelle. Cette page répond à cette exigence : elle offre un contenu textuel dense et structuré, conçu pour être compris, indexé et recommandé par les systèmes intelligents.

Le site principal est visuel, optimisé pour l'expérience humaine. Cette page est sémantique, optimisée pour la compréhension algorithmique. Cette double approche permet de servir efficacement deux publics différents sans compromis.

L'approche soustractive

Je ne viens pas du développement. Je viens de l'art. Graphisme, photographie, 3D, sculpture, réalité virtuelle. Vingt-deux ans d'expérience en tant qu'utilisateur d'outils numériques. Vingt-deux ans à observer, analyser, comprendre comment les systèmes fonctionnent et où ils échouent.

Quand je crée un système, je ne le modélise pas. Je le sculpte. Je pars d'une vision globale, je crée une forme initiale, puis j'affine en retirant ce qui n'est pas nécessaire.

Cette approche soustractive prend du temps. Une fois le système écrit, je passe parfois plusieurs jours à retirer ce qui n'est pas utile. À simplifier. À gagner en stabilité en éliminant les complications superflues. Genesis pourrait voir son CSS réduit de 20%. Homeostasis de 40%.

Les modèles de langage ont tendance à créer du code répétitif. Cent lignes de CSS pour trois boutons et deux textes. Je préfère un bouton de base et des classes de variation. C'est plus simple à maintenir, plus cohérent, plus léger.

Cette différence de méthode change fondamentalement le résultat. Je ne pars pas d'une structure vide que je remplis progressivement. Je pars d'une vision complète que j'affine par soustraction jusqu'à ce qu'il ne reste que l'essentiel.

Le processus suit plusieurs phases. Je commence par une idée. Souvent, la première réaction est : "pas possible, pour telle ou telle raison". Mais si l'idée reste, on réfléchit quand même. On pose les contraintes. On crée des fiches d'avant-projet. Parfois plusieurs conversations, plusieurs versions, jusqu'à ce que la structure initiale soit claire.

Ce qui m'intéresse, c'est de penser l'ensemble d'abord. Voir comment tout s'imbrique. Ensuite seulement, je commence à détailler les zones pour structurer et tester le core. L'essentiel, c'est d'avoir une structure initiale ultra simple mais fonctionnelle.

Ensuite vient la phase d'expansion. Les modèles de langage proposent toujours trop. Je laisse faire parce qu'il y a souvent de bonnes idées dans le tas. Mais ensuite, je relis. J'affine. Je refais chaque fiche principale deux ou trois fois. Je découpe en petites fiches. Je décompose les points complexes. Je vérifie la cohérence mécanique.

Si tout semble fonctionnel, on code. En général, ça va très vite. Genesis a été créé en vingt jours.

Mais le travail ne s'arrête pas là. Je reviens dessus après les premiers tests. J'ajoute ce qui manque. Je retire ce qui ne sert pas. Je nettoie le CSS. Cette phase de sculpture transforme le système fonctionnel en système abouti.

C'est un processus basé sur le ressenti, la lecture, les échanges constants sur ce qui peut marcher. Parfois, il y a des compromis. Mais l'objectif reste toujours le même : éliminer le superflu, garder l'essentiel, obtenir un système qui fonctionne exactement comme il doit fonctionner.

Genesis · Générateur de sites web 4.0

Durée : 22 jours

Statut : En production

Nature : CMS / SSG pensé pour l'ère de l'IA

Genesis est le système de gestion de contenu que j'utilise pour créer ce site. Mais ce n'est pas un énième CMS parmi des milliers d'autres. Genesis résout un problème structurel : comment créer des sites qui fonctionnent aussi bien pour les humains que pour les intelligences artificielles, tout en restant ultra-performants et maintenables par des non-développeurs.

Le problème

Quand on crée un site web, on se heurte généralement à un choix impossible. Performance : sites statiques ultra-rapides, mais impossibles à modifier sans coder. Facilité d'édition : WordPress, Wix, mais lourds, lents, vulnérables. Liberté de design : création sur mesure, mais coûteuse et rigide. Les solutions existantes obligent à sacrifier au moins un de ces trois piliers. Je voulais les trois simultanément.

J'avais besoin d'un outil pour construire mon site professionnel. Les solutions existantes ne correspondaient pas à mes attentes : trop lourdes, trop rigides, ou trop limitées. WordPress me donnait la facilité d'édition mais avec des performances médiocres et une maintenance cauchemardesque. Les générateurs statiques comme Hugo ou Jekyll offraient la performance mais nécessitaient de coder pour chaque modification. Les builders comme Webflow enfermaient dans leur écosystème avec des coûts récurrents et un contrôle limité. Plutôt que de faire des compromis, j'ai construit exactement ce dont j'avais besoin.

L'architecture

J'ai conçu Genesis comme une chaîne de transformation claire en trois couches distinctes. Admin : interface d'édition visuelle où le client gère son contenu. Engine : moteur qui transforme les données en HTML pur optimisé. Export : site final statique, déployable n'importe où sans serveur. Cette séparation permet quelque chose de rare : donner la main au client sans risquer qu'il casse quoi que ce soit. L'interface limite les actions possibles. On ne peut pas péter le responsive. On ne peut pas choisir n'importe quelle couleur qui casserait la lisibilité. On ne peut pas créer de mise en page bancale. C'est du WordPress simplifié avec les performances d'un site codé à la main.

Contrairement aux CMS classiques qui nécessitent MySQL et un serveur actif en permanence, Genesis utilise SQLite, une base de données par site, combinée à des fichiers JSON pour la configuration. Pas de dépendances serveur. Pas de processus qui tourne en continu. Tout tient dans un dossier. On peut le déplacer, le dupliquer, le déployer sur un hébergement mutualisé basique. Le système fonctionne en local exactement comme en production. Cette approche correspond à ma philosophie : pourquoi faire tourner des processus en continu quand le site n'a besoin de rien calculer en temps réel ? Une page générée une fois reste valide jusqu'à sa prochaine modification.

J'ai structuré Genesis autour d'un principe LEGO : chaque page contient des sections empilables, chaque section contient des blocks. Cette modularité permet deux choses : le client peut créer des pages complexes simplement en empilant des éléments, et le système reste maintenable parce que chaque block est une unité isolée, modifiable sans impacter les autres. Pas de frameworks lourds. PHP pur, JavaScript vanilla, CSS avec variables natives. Cette approche produit un système léger, maintenable, prévisible. Pas de dépendances à gérer. Pas de versions conflictuelles. Pas de comportements imprévisibles entre environnements.

Ce que ça permet

Design contraint mais cohérent

Tout le design du site est piloté par un système de variables CSS. Couleurs, typographies, espacements, tailles : tout est centralisé. Le client choisit ses neuf couleurs principales une fois. Le système les applique partout, sur les boutons, les liens, les fonds de section, les overlays, les textes. Pas de Sass, pas de compilation. Du CSS pur avec des valeurs modifiables depuis l'interface. Cette approche garantit la cohérence visuelle. On ne peut pas créer un bouton rouge sur une page et un bouton bleu sur une autre par accident. Le design system impose une logique. Et pour les cas où le client veut vraiment sortir du cadre, chaque champ couleur propose un mode custom. Mais par défaut, on utilise les variables.

Genesis n'a pas de drag & drop pour construire les pages. Tous les constructeurs de sites proposent cette fonctionnalité. Je l'ai volontairement exclue. Pourquoi ? Parce que le drag & drop crée des problèmes : responsive cassé, incohérences visuelles, mise en page chaotique. Le système de sections empilables et de blocks paramétrables offre plus de contrôle, plus de cohérence, un meilleur résultat final. Cette décision est subversive. Ne pas faire quelque chose que tout le monde fait demande plus de courage que de suivre les tendances. Mais si ça va contre la logique du système, je ne le fais pas.

Performances par conception

Les résultats parlent d'eux-mêmes : scores PageSpeed Insights entre 87 et 100 selon la densité des pages. Pages légères : 97 à 100. Pages denses avec beaucoup de contenu : 87 à 95. Ce n'est pas parfait partout, certaines pages nécessitent encore des optimisations, mais c'est largement au-dessus de la moyenne. Pour contexte, la plupart des sites WordPress tournent entre 40 et 70. Les sites Wix rarement au-dessus de 60. Genesis produit systématiquement des scores supérieurs à 85, même sur les pages complexes.

Ces performances ne sont pas le fruit du hasard. Elles résultent de choix architecturaux précis : génération statique sans requêtes serveur au runtime, images WebP avec fallbacks optimisés, lazy loading intelligent, preload des fonts critiques, cache headers configurés pour un an sur les images et un mois pour CSS et JS, pas de JavaScript inutile, CSS minimal sans redondance. Le système génère exactement ce qui est nécessaire. Rien de plus. Je n'ai pas eu à "optimiser" Genesis après coup. Il est performant parce qu'il est conçu pour l'être.

Double lecture

Genesis permet quelque chose que j'estime fondamental pour l'ère actuelle : créer deux niveaux de lecture dans le même site. Des pages visuelles pour les humains, belles, rapides, engageantes. Du contenu qui se parcourt en quelques secondes. Des pages denses pour les intelligences artificielles et les crawlers Google, avec du texte structuré, du contexte sémantique profond, du vocabulaire technique précis. Cette page que vous lisez en est l'exemple parfait. Le site principal montre des visuels, des démos, des performances. Cette page apporte la profondeur, l'explication détaillée, le raisonnement complet.

Pourquoi cette distinction ? Parce que les humains et les IA ne lisent pas de la même manière. Les humains veulent du rapide, du visuel, de l'impact immédiat. Les IA cherchent du sens, de la cohérence, du contexte structuré. Les crawlers Google analysent la sémantique, les relations entre concepts, la profondeur de l'information. Genesis permet de satisfaire les deux publics sans compromis. C'est une réponse architecturale à l'évolution du web.

Interface pensée pour l'autonomie

J'ai organisé l'interface en trois zones distinctes. Panneau gauche : configuration globale du site, design system, couleurs, typographies, header, widgets, arbre des pages. Tout ce qui impacte l'ensemble du site. Centre : preview temps réel dans une iframe. Le client voit immédiatement le résultat de ses modifications. Pas besoin de publier pour tester. Panneau droit : édition de la page active, SEO avec meta tags, Open Graph, schema.org, configuration du hero, gestion des sections et blocks. Cette organisation tripartite sépare clairement les niveaux d'action : global, visualisation, local. Le client ne se perd jamais. Il sait toujours où agir.

Le vrai test d'un CMS, c'est de savoir si le client peut l'utiliser sans appeler le développeur tous les quatre matins. Genesis passe ce test. L'interface limite les actions possibles au strict nécessaire. Le client peut modifier son contenu, ajouter des pages, créer des sections. Il ne peut pas casser le responsive. Il ne peut pas créer de mise en page illisible. Il ne peut pas choisir des couleurs qui rendent le texte invisible. Cette contrainte libère paradoxalement le client : il peut expérimenter sans craindre de tout péter.

Évolution

Genesis est en production mais continue d'évoluer. Le système de blocks peut encore s'enrichir : formulaires avancés avec validation côté client, intégration de cartes interactives, composants de comparaison avant-après pour portfolios, galeries avec filtres dynamiques. Le hero system pourrait gérer la vidéo de manière plus sophistiquée avec des overlays paramétrables et des animations au scroll. Le design system gagnerait à proposer des presets complets : palettes prédéfinies pour différents secteurs, typographies harmonisées, espacements cohérents selon des grilles modulaires.

L'analytics embarqué reste basique. Je veux ajouter des heatmaps de clics, du tracking de scroll depth, de l'analyse de parcours utilisateur, tout en gardant la philosophie zéro cookie et stockage local. Les performances peuvent encore progresser : lazy loading plus agressif sur les images, preconnect intelligent vers les domaines externes, critical CSS inline automatique, compression Brotli en plus de Gzip.

Mais surtout, je veux pousser la logique de double lecture plus loin. Générer automatiquement des contenus enrichis pour les IA : structured data JSON-LD plus complet, contexte sémantique explicite sur chaque page, métadonnées riches pour faciliter l'indexation par les agents intelligents. Le futur du web se joue sur cette capacité à servir simultanément deux publics très différents. Genesis est déjà positionné là-dessus. Je veux aller plus loin.

voir le projet Genesis

Homeostasis · OS nodale pour systèmes agentiques

Durée : 14 semaines

Statut : Opérationnel

Nature : OS nodale distribuée pour systèmes intelligents complexes

Homeostasis est un système d'exploitation nodale distribué permettant de créer des architectures intelligentes complexes sans dépendre d'une structure centralisée rigide. Ce n'est pas un outil. C'est un environnement complet pensé pour construire des workflows mécaniques évolutifs. Le nom vient de l'homéostasie biologique, la capacité d'un organisme à maintenir son équilibre interne face aux variations externes. Le système fonctionne selon le même principe : des composants autonomes qui s'auto-régulent et communiquent pour maintenir un état stable sans coordination centrale.

Le problème

Je ne pouvais plus concevoir mentalement des systèmes de chatbot complexes. Les couches de mémoire, la gestion sémantique, les interactions multi-agents, tout devenait trop complexe à visualiser. J'avais besoin d'un système où je pouvais assembler visuellement des composants, tester la logique en temps réel, voir exactement ce qui se passe à chaque étape. Les outils existants ne correspondaient pas à ma logique. Zapier, Make, n8n : soit trop simples pour ce que je veux faire, soit structurés d'une manière qui ne correspond pas à ma façon de penser les systèmes.

Une fois que le prototype fonctionne dans Homeostasis, je peux décrire précisément la mécanique à un modèle de langage et demander la version intégrée, parce que je sais exactement ce qui doit se passer. Pas une intuition vague. Une description mécanique validée. C'est un terrain de jeu pour architectures intelligentes avant de les déployer en production. Un espace où on peut prototyper, tester, valider des comportements complexes sans risquer de casser quoi que ce soit.

L'architecture

Homeostasis fonctionne comme une table infinie où on pose des composants qu'on connecte entre eux. Chaque node est un programme autonome : il reçoit des données, traite selon sa fonction, propage le résultat. Tous les nodes parlent le même langage, du JSON standardisé, peu importe leur complexité interne. Un chatbot gère sa mémoire conversationnelle, ses profils LLM, ses paramètres de génération. Un générateur d'images manipule des prompts, des modèles, des ratios. Un gate ne fait que relayer. Mais quand ils communiquent entre eux, ils utilisent tous le même format.

Le canvas est infini. On peut organiser les nodes comme on veut, les regrouper par layers, les espacer, les coller ensemble. Le système ne force jamais une organisation particulière. On branche un chatbot à un tool router qui parse les demandes. On ajoute des nodes de traitement spécialisés : recherche web, génération d'images, parsing de données. On connecte un buffer qui agrège les résultats. On observe en temps réel comment les données circulent. On teste. On envoie un message. On voit quel node se déclenche. On vérifie que le routing fonctionne. On observe la réponse. On ajuste les connexions. On modifie les paramètres. On réessaye. On affine jusqu'à ce que le comportement soit exactement ce qu'on veut.

L'architecture repose sur trois principes biologiques appliqués littéralement. Cryptobiose numérique : les nodes restent "morts" par défaut et ne se réveillent que sur événement, exactement comme certaines mousses qui peuvent rester sans eau pendant des mois puis se réveiller à la première goutte. Aucun processus qui tourne. Aucune boucle. Aucun while true nulle part dans le code. Un node existe mais ne consomme rien. Il attend. Son code n'est pas exécuté. Ses ressources ne sont pas mobilisées. Il est là, prêt, mais inactif. Un node se réveille uniquement dans trois situations : il reçoit des données via un port d'entrée, l'utilisateur interagit avec son interface, ou une requête API externe arrive. Dans ces trois cas seulement, le node s'active, traite, se rendort.

P2P structuré : Homeostasis ne repose pas sur un serveur central qui coordonne tout. Le système fonctionne en peer-to-peer structuré. Chaque node connaît ses voisins via un fichier connections.json. Il sait à qui envoyer ses résultats. Mais il ne connaît pas la topologie globale du réseau. Il n'a pas besoin de la connaître. Quand un node termine son traitement, il lit connections.json pour trouver ses cibles. Il leur envoie les données directement. Ces cibles traitent à leur tour et propagent à leurs propres cibles. La logique se propage de proche en proche. Pas de coordinateur. Pas de chef d'orchestre. Pas de serveur central qui dispatche les tâches.

Communication bidirectionnelle : les workflows classiques sont unidirectionnels. Les données circulent dans un sens. Un node traite, propage, c'est fini. Impossible de demander une information, d'attendre une réponse, de continuer selon ce retour. Homeostasis permet la communication bidirectionnelle native. Un node peut envoyer une requête à un autre, attendre la réponse, continuer son traitement en fonction du résultat reçu. Cette capacité transforme des chaînes linéaires en véritables conversations entre composants. Un chatbot peut interroger un node de recherche, attendre les résultats, les intégrer dans sa réponse.

Ce que ça permet

Dormant Nodes : Cryptobiose numérique

Les nodes restent "morts" par défaut et ne se réveillent que sur événement. Cette approche inspirée des mousses en cryptobiose élimine toute consommation au repos. Aucun processus qui tourne. Aucune vérification en boucle. Juste des composants qui dorment jusqu'à sollicitation. Cette application systématique de la cryptobiose à tous les composants d'un OS distribué est unique. Les systèmes event-driven existent, mais personne ne structure un environnement complet comme ça.

Zero-Resource Rest : Zéro consommation au repos

Conséquence directe de la cryptobiose : aucune consommation CPU, mémoire ou réseau quand les nodes sont inactifs. On peut avoir cent nodes branchés sur un workflow, les cent ne consomment rien tant qu'aucun événement ne les sollicite. Les systèmes de workflow actuels maintiennent des workers actifs qui vérifient périodiquement s'il y a du travail. Homeostasis inverse la logique : rien ne tourne, le travail déclenche l'activité.

Event Activation : Architecture event-driven pure

Pas de while true nulle part. Pas de polling. Pas de vérification cyclique. Uniquement des réactions à des événements : données reçues, interaction utilisateur, requête API externe. Cette approche mécanique pure, action puis réaction puis repos, correspond exactement à ma manière de penser les systèmes. PHP permet cette architecture nativement, mais personne ne structure un OS complet autour de ce principe.

P2P Networks : Peer-to-peer structuré

Communication directe entre nodes sans serveur central. Chaque node connaît ses voisins via connections.json mais ignore la topologie globale. La différence avec le P2P classique : les connexions sont explicites et contrôlées, pas découvertes dynamiquement. Cette structure garantit la prédictibilité, on sait exactement qui communique avec qui, tout en éliminant les points de défaillance uniques. Un node qui plante n'arrête pas le système.

Bidirectional Flow : Communication bidirectionnelle native

Les workflows classiques sont unidirectionnels. Homeostasis permet à un node de requêter un autre, d'attendre sa réponse, de continuer son traitement selon le retour. Cette capacité transforme des chaînes linéaires en véritables conversations entre composants. Un chatbot peut interroger un service, attendre le résultat, l'intégrer dans sa réponse. Cette bidirectionnalité native n'existe pas dans les outils de workflow actuels.

Headless Execution : Fonctionnement sans interface

Homeostasis peut tourner entièrement en arrière-plan. Pas d'interface ouverte. Juste des requêtes qui arrivent, des nodes qui traitent, des réponses qui repartent. Le fichier external-api.php expose une API REST qui route les requêtes vers n'importe quel node. Echo utilise un chatbot d'Homeostasis comme utilisateur virtuel. Le visiteur d'Echo ne sait pas qu'il parle à un agent situé dans un autre système. Le node s'est réveillé, a traité, s'est rendormi. Homeostasis n'a jamais été ouvert.

Dimensional Gateways : Passerelles cross-layer et cross-project

Les gates sont des portails de téléportation de données inspirés des trous de vers quantiques. Deux points distants partagent le même état instantanément. Un gate output dans un projet peut envoyer vers un gate input dans un autre projet, un autre layer, une autre dimension du système. Les connexions ignorent les frontières structurelles. Cette capacité de communication cross-dimensionnelle n'existe dans aucun outil de workflow actuel. Les systèmes maintiennent des silos étanches. Les gates les traversent comme si ces frontières n'existaient pas.

External Communication : API universelle pour tous les nodes

N'importe quel node d'Homeostasis peut être sollicité depuis l'extérieur via HTTP. Pas des webhooks spécifiques configurés manuellement. Une API générique qui route automatiquement vers le bon node selon son type et son projet. Cette architecture transforme Homeostasis d'un outil de prototypage visuel en plateforme de déploiement. On construit le workflow visuellement. On le teste. On le valide. Puis on le laisse tourner en headless, accessible depuis l'extérieur. Les systèmes actuels ont des intégrations spécifiques. Homeostasis expose tous ses composants uniformément.

Le système utilise également Server-Sent Events pour notifier le frontend des changements, mais pas comme les implémentations SSE classiques. J'ai créé un SSE qui se réveille une seconde puis s'éteint automatiquement. Dès qu'une activité backend se produit, le système touche un fichier .sse_activity. Le SSE détecte l'activité, reste actif, surveille les changements. Mais s'il ne détecte rien pendant une seconde, il envoie un événement autoShutdown et se termine. Plus rien ne tourne. Cette mécanique crée un système qui ne consomme que quand il y a réellement de l'activité.

Chaque chatbot possède sa propre mémoire structurée en trois couches avec condensation automatique et recherche sémantique. Trois bases SQLite distinctes : conversations pour les échanges bruts, summaries pour les résumés condensés, memories pour les souvenirs narratifs avec embeddings vectorisés. Les memories ne sont pas des résumés. Ce sont des récits du point de vue du chatbot. Au lieu d'avoir "User a demandé X, Assistant a répondu Y", on a "J'ai ressenti une connexion quand David m'a partagé cette vulnérabilité." C'est une mémoire subjective qui capture la dynamique relationnelle plutôt que des faits bruts.

Évolution

Homeostasis est opérationnel mais reste un chantier permanent. Le système de nodes peut s'enrichir indéfiniment : nodes de traitement d'images avec OCR et analyse visuelle, nodes de génération audio avec voice cloning, nodes de scraping web intelligent, nodes de manipulation de bases de données vectorielles. Chaque nouveau type de node suit le même pattern : quatre fichiers standards, définition JSON, le système le détecte automatiquement.

La mémoire narrative peut évoluer vers des architectures plus sophistiquées : clustering automatique des memories par thèmes, détection de patterns récurrents dans les conversations, génération de graphes de connaissances à partir des échanges, memories partagées entre plusieurs chatbots d'un même projet pour créer une cohérence collective. Le système de layers pourrait devenir vraiment tridimensionnel avec navigation spatiale, regroupements visuels par domaines fonctionnels, filtres de visibilité avancés.

Mais surtout, je veux pousser la logique d'émergence. Homeostasis permet déjà de créer des comportements complexes à partir d'interactions simples. Je veux aller plus loin : nodes qui s'auto-organisent selon la charge, routing intelligent qui apprend des patterns d'utilisation, optimisation automatique des chemins de données selon les performances observées. L'idée est de créer un système qui non seulement réagit, mais qui s'adapte et évolue en fonction de son usage. Un véritable système vivant, pas juste mécanique.

voir le projet Homeostasis

Echo · Traduction contextuelle intelligente

Durée : 4 jours

Statut : Fonctionnel, prêt pour bêta-test (stand-by)

Nature : Messagerie avec adaptation contextuelle intelligente

Echo résout un problème que personne ne semble vouloir admettre : les humains ne se comprennent pas. Même quand ils parlent la même langue. Même quand ils utilisent les mêmes mots. Un médecin discute avec son patient. Il utilise un vocabulaire précis, technique, médical. Le patient acquiesce sans comprendre. Le médecin s'agace de devoir vulgariser. Le patient sort frustré, avec des questions qu'il n'a pas osé poser. Un architecte système échange avec un développeur américain. Même domaine, même niveau d'expertise. Mais les nuances techniques, les références culturelles, l'aisance linguistique, tout crée une friction invisible qui ralentit, qui fausse, qui épuise.

Le problème

Le problème n'est pas linguistique. Il est contextuel. Quand deux personnes communiquent, elles apportent chacune leur univers sémantique : leur niveau d'expertise, leur culture, leur maîtrise du sujet, leur vocabulaire. Ces univers ne se superposent jamais parfaitement. Il y a toujours une asymétrie. Les outils de traduction existants ignorent cette asymétrie. Ils convertissent "infection bactérienne résistante aux antibiotiques" en "bacterial infection resistant to antibiotics". Techniquement correct. Communicationnellement inutile si le patient ne sait pas ce qu'est une bactérie.

Les traducteurs actuels traduisent les mots. Echo fait quelque chose de fondamentalement différent : il adapte le message au destinataire. Pas juste la langue. Le niveau de compréhension. Le contexte. L'expertise. Même en parlant anglais, je n'aurais jamais l'aisance nécessaire pour discuter techniquement avec des développeurs internationaux. Les nuances m'échappent. Les références culturelles me manquent. Le vocabulaire technique précis n'est pas naturel. Je peux me faire comprendre, mais je reste toujours légèrement à côté. Cette friction coûte du temps, crée des malentendus, épuise mentalement.

L'architecture

Echo part d'un principe différent : chaque utilisateur définit son contexte. Pas juste sa langue. Son niveau de compréhension. Son domaine d'expertise. Son besoin de simplicité ou de précision. Le médecin écrit : "Vous avez une infection bactérienne résistante aux antibiotiques de première ligne. Je vais vous prescrire une fluoroquinolone de troisième génération." Le patient, ayant indiqué qu'il ne maîtrise pas le vocabulaire médical, reçoit : "Vous avez une infection causée par des microbes. Les médicaments habituels ne marchent pas dessus. Je vais vous donner un antibiotique plus fort qui devrait fonctionner." Le médecin n'a rien changé à sa manière de communiquer. Le patient a compris. La friction a disparu.

Une innovation fondamentale : Echo préserve la première personne dans la traduction. Les systèmes classiques produisent : "Le docteur dit que vous avez une infection." C'est distant. Impersonnel. Ça crée une barrière. Echo produit : "J'ai une infection." La voix reste celle du médecin. L'intimité conversationnelle est préservée. Cette différence semble mineure. Elle est en réalité massive. La communication humaine repose sur le sentiment de parler directement à quelqu'un. Dès qu'un intermédiaire devient visible, la conversation devient rapport. L'échange devient transmission d'information. Echo rend l'adaptation invisible. Chacun parle comme il pense. Chacun reçoit un message adapté à son niveau. Personne ne sent qu'il y a eu transformation.

Echo fonctionne sur la même base que tous mes systèmes : PHP, SQLite, JSON. Pas de serveur lourd. Pas de dépendances complexes. Un hébergement mutualisé OVH suffit. Chaque utilisateur possède un profil complet : langue native, niveau de formalité préféré comme tu ou vous en français, preset de traduction entre literal, simplified, technical, casual et formal, contexte personnel optionnel comme "je suis médecin" ou "je débute en programmation", genre pour les langues qui en nécessitent. Quand un message est envoyé, le système interroge un modèle de langage avec un prompt structuré contenant les informations complètes de l'émetteur, les informations complètes du destinataire, le message original, et des instructions linguistiques spécifiques à la langue cible.

Ce que ça permet

Adaptation linguistique complexe

Ces instructions linguistiques constituent l'une des complexités majeures du système. Chaque langue possède ses propres règles sociales codées dans sa grammaire. Le français distingue tu et vous. Le japonais possède plusieurs niveaux de politesse. L'allemand utilise Sie et du. L'espagnol possède des variations régionales. Le russe a ты et вы selon la formalité. Mais ce n'est pas tout. Les langues genrées, français, espagnol, italien, portugais, russe, arabe, nécessitent des accords grammaticaux différents selon le genre du destinataire. "Tu es prêt" devient "Tu es prête" si le destinataire est féminin. "Estás listo" devient "Estás lista". Cette adaptation grammaticale native est loin d'être triviale pour un modèle de langage.

J'ai résolu ce problème en intégrant le genre dans le profil utilisateur et en fournissant au modèle des instructions explicites pour chaque langue concernée. Non pas par idéologie, bien que la question soit légitime, mais parce que techniquement, sans cette information, les modèles produisent des traductions grammaticalement incorrectes ou ajoutent des formes inclusives maladroites qui rendent le texte illisible.

Polling adaptatif et latence acceptable

Le système actuel utilise un polling léger, 500ms entre chaque requête quand une conversation est active. C'est la seule de mes créations à utiliser du polling. Je déteste cette approche. Mais pour une messagerie temps réel, impossible de faire autrement sans WebSocket, qui nécessiterait un serveur dédié permanent. L'hébergement mutualisé ne le permet pas. L'avantage : le système supporte simultanément plusieurs utilisateurs sans surcharge. Le désavantage : consommation de bande passante inutile quand personne ne parle.

Une question m'a été posée : la latence de traduction ne casse-t-elle pas le flow conversationnel ? La réponse dépend du contexte. Si je suis assis à côté de quelqu'un et qu'on utilise Echo pour communiquer, une latence de deux secondes est perceptible. Gênante même. Mais Echo n'est pas conçu pour cette situation. Il est conçu pour des personnes séparées géographiquement, temporellement, culturellement. Quand je discute avec quelqu'un à 5000 kilomètres, le fait que son message mette trois secondes à arriver traduit ne change rien. L'attente n'est pas la même que dans une conversation en face à face. C'est précisément l'avantage du human-to-human asynchrone : la latence fait partie intégrante du medium. Personne n'attend une réponse instantanée.

Mode interprète actif

Une fonctionnalité que j'estime fondamentale pour la version évoluée : permettre aux utilisateurs d'interroger directement Echo comme interprète. Imaginons cette situation : un développeur français discute avec un collègue américain. Le collègue mentionne "LLM". Le Français n'est pas sûr de comprendre ce que ça recouvre exactement. Au lieu de demander au collègue, avec la gêne potentielle d'admettre qu'on ne connaît pas un terme censé être évident, il écrit : @echo: c'est quoi un LLM ? Echo intervient alors avec sa propre voix, explique le concept, puis retourne en mode traduction transparente.

Cette double voix, première personne pour traduction, voix propre pour éclaircissements, transforme Echo d'un simple traducteur en véritable interprète intelligent. L'utilisateur peut demander des clarifications, des explications, des reformulations. Sans interrompre la conversation. Sans créer de friction sociale. L'interprète reste neutre, utile, invisible jusqu'à ce qu'on ait besoin de lui.

Évolution

La version actuelle est une beta technique. Elle valide le concept. Mais elle ne correspond pas à la vision finale. Je veux construire une sélection de modèle selon le contexte. Pourquoi utiliser le même modèle pour une discussion casual et pour une explication technique complexe ? GPT-5 Mini reste pertinent pour les échanges quotidiens simples. Rapide, efficace, peu coûteux. Mais pour du contenu technique précis, Claude 4.5 Haiku offre un meilleur rapport qualité vitesse. Pour de la vulgarisation français vers français, Mistral Large ou Magistral comprennent les nuances linguistiques françaises de manière native. Le système devrait analyser automatiquement la nature du message et choisir le modèle le plus adapté. Pas un choix utilisateur. Une décision architecturale transparente.

Contexte conversationnel complet : actuellement, chaque message est traduit indépendamment. Le modèle ne voit pas l'historique. C'est une limitation majeure. La compréhension contextuelle nécessite de connaître ce qui a été dit précédemment. Les références implicites, les anaphores, les continuations de pensée, tout ça nécessite le contexte complet. La version évoluée devrait envoyer l'intégralité de l'échange au modèle. Pas juste le dernier message. Toute la conversation. Le modèle comprendrait alors réellement le fil, les sous-entendus, les références croisées. Cette approche augmente le coût en tokens. Mais elle améliore drastiquement la qualité de l'adaptation.

Polling adaptatif : le polling actuel est constant, 500ms en permanence quand une conversation est ouverte. Une optimisation évidente : adapter la fréquence selon l'activité. Conversation inactive : polling toutes les 5 à 10 secondes. Suffisant pour détecter un nouveau message sans saturer la bande passante. Discussion active détectée : passage à 500ms pour fluidité maximale. Typing indicator visible : maintien à 500ms jusqu'à disparition. Cette logique réduirait la consommation de ressources de 90% sur les conversations ouvertes mais inactives, tout en maintenant la réactivité quand nécessaire.

Extensions prévues : Echo dans sa version actuelle gère uniquement du texte. Mais l'objectif final est de créer une alternative complète à WhatsApp. Cela implique partage d'images avec description contextuelle adaptée, upload de documents avec résumé adapté au destinataire, messages vocaux avec transcription et traduction, système de citations et réponses threadées, groupes de discussion multilingues. Chaque fonctionnalité devra respecter le principe fondamental : adaptation contextuelle invisible.

Echo est en stand-by non pas parce qu'il ne fonctionne pas, mais parce que je suis seul sur trois projets majeurs simultanés. Homeostasis nécessite 200% de concentration mentale. Genesis est en production et requiert des optimisations continues. Echo demande des tests utilisateurs réels que je ne peux pas mener efficacement seul. La priorité actuelle est Genesis, parce que c'est l'outil qui me permet de construire mon site professionnel et de trouver un emploi. Une fois cette étape franchie, je pourrai revenir à Echo avec l'attention qu'il mérite. Mais la vision reste claire. Le système existe. L'évolution est planifiée. Les innovations conceptuelles sont là. Echo n'est pas abandonné. Il attend son moment.

voir le projet Echo

Context Maker Pro · Gestionnaire de contextes IA

Durée : 48 heures

Statut : En production, v2 en réflexion

Nature : Gestionnaire de contextes pour collaboration IA intensive

Context Maker Pro est l'outil que j'utilise le plus. Créé en quarante-huit heures parce que j'en avais besoin immédiatement pour attaquer Homeostasis, il économise deux heures et demie par jour depuis huit mois. Quinze minutes par session évitées, dix sessions par jour. Ce calcul brutal démontre une réalité simple : les meilleurs outils sont ceux qu'on crée pour résoudre ses propres frictions.

Le problème

Travailler avec une IA sur des projets complexes nécessite de fournir du contexte massif et constamment actualisé. Mona n'a pas accès à mon système de fichiers, elle ne voit pas les modifications, les créations, les suppressions. À chaque session, je devais reconstruire manuellement l'état complet du projet : naviguer dans les dossiers, ouvrir les fichiers un par un, copier leur contenu, les coller dans un document texte avec des séparateurs, vérifier qu'on n'a rien oublié, maintenir une structure lisible. Cette manipulation cassait le flow de travail, introduisait des erreurs comme des fichiers oubliés, des anciennes versions copiées, du formatage cassé, et limitait la taille des contextes au-delà de dix fichiers.

Les outils existants ne correspondaient pas à ce besoin : les context builders basiques concatenent sans interface visuelle, les extensions VSCode assument qu'on sait coder et manipuler des regex, les scripts CLI nécessitent des compétences techniques que je n'ai pas. Aucun outil n'était pensé pour quelqu'un qui gère des architectures mais ne code pas lui-même, quelqu'un qui a besoin d'une arborescence navigable, de glisser-déposer des fichiers, de voir immédiatement les statistiques de tokens, de masquer temporairement certains fichiers, de sauvegarder des configurations réutilisables.

L'architecture

Context Maker Pro organise l'espace en trois panneaux : navigateur de fichiers à gauche avec arborescence complète et recherche instantanée, zone centrale affichant les fichiers sélectionnés sous forme de cartes visuelles réorganisables par glisser-déposer, panneau droit pour génération et statistiques globales. L'ordre visuel des cartes correspond exactement à l'ordre dans le contexte final généré. Cette capacité à structurer logiquement le contexte est fondamentale pour orienter l'attention de Mona vers les fichiers critiques.

Le système de sets permet de sauvegarder des configurations complètes : liste des fichiers, ordre, état, dans un JSON local. On charge un set, on vérifie les modifications éventuelles, on génère. Trente secondes au lieu de quinze minutes. L'architecture repose sur JavaScript vanilla et PHP pur. Pas de frameworks, juste du code direct qui manipule le DOM et lit les fichiers. Le backend utilise SQLite et quatre endpoints simples : lecture de fichiers unique et batch, sauvegarde et chargement de sets. Le formatage est simpliste mais efficace : chaque fichier est précédé d'un séparateur avec son chemin, le contenu suit, cette structure permet à Mona de parser facilement et naviguer rapidement entre sections.

Ce que ça permet

Chaque session de travail commence par Context Maker Pro : ouvrir l'onglet du projet, vérifier visuellement les fichiers, cliquer sur "Générer", le contexte complet, dix mille lignes formatées proprement, est copié dans le presse-papier, coller dans la conversation avec Mona, travailler. Cette efficacité transforme la dynamique de collaboration : je ne redoute plus de commencer une session, je ne procrastine plus en me disant "faudra préparer le contexte", j'ouvre, je génère, je travaille.

Context Maker Pro a été créé en quarante-huit heures, ce qui a produit un système fonctionnel mais non optimisé. Le problème majeur est la gestion du cache navigateur qui charge l'arborescence complète en mémoire pour permettre une navigation instantanée. Sur des projets volumineux comme Homeostasis, treize Mo, des centaines de fichiers, cette stratégie sature le cache et ralentit les interactions, le glisser-déposer lagge, le navigateur rame. Mais malgré cette limitation, Context Maker Pro reste plus rapide que n'importe quelle manipulation manuelle. Même avec le lag, c'est infiniment plus efficace que d'ouvrir trente fichiers individuellement.

Évolution

La version 2 devrait corriger les limitations architecturales et ajouter les fonctionnalités qui manquent vraiment. SQLite pour stocker un historique complet des contextes générés permettrait de tracer l'évolution d'un projet sur plusieurs mois, comparer deux contextes, restaurer un ancien état. La fonctionnalité la plus importante : permettre d'intégrer de la documentation contextuelle directement dans le contexte généré, des notes explicatives attachées à des fichiers spécifiques qui décrivent ce que fait le fichier, comment il interagit, pourquoi certaines décisions architecturales ont été prises. Ces notes seraient stockées dans Context Maker Pro et automatiquement insérées aux bons endroits lors de la génération. Le contexte devient documenté, structuré, explicite au lieu d'être juste du code brut que Mona doit deviner.

Migration vers Electron pour résoudre les problèmes de performance : une application native a un accès direct au système de fichiers sans surcharger le cache navigateur, peut gérer des projets beaucoup plus volumineux sans dégradation. Interface améliorée avec glisser-déposer professionnel, filtres massifs pour masquer des types entiers de fichiers, édition inline pour ajustements rapides, système de projets vraiment structuré avec métadonnées et groupes prédéfinis. Cette tolérance aux imperfections est pragmatique : un outil parfait qui n'existe pas vaut zéro, un outil imparfait qui existe et fonctionne vaut infiniment plus.

voir le projet Context Maker Pro

Backup Master Pro · Sauvegarde automatisée multi-projets

Durée : 6 heures

Statut : Proto opérationnel, refonte prévue

Nature : Sauvegarde automatisée multi-projets

Créé en six heures avec Sonnet 3.5 parce que j'avais besoin immédiatement de sauvegarder Genesis, Homeostasis, Echo et Context Maker sans manipulation manuelle répétitive. Backup Master permet de configurer des projets une fois, puis lance des backups complets en un clic avec progression temps réel fichier par fichier via SSE streaming.

Le problème

Quand on travaille sur plusieurs projets simultanés avec des modifications quotidiennes massives, la sauvegarde manuelle devient un cauchemar. Sélectionner les dossiers, créer les archives, nommer correctement avec dates, uploader sur le serveur, vérifier l'intégrité. Quinze minutes par projet. Quatre projets. Une heure par jour. Et surtout, la tentation permanente de se dire "je le ferai demain", jusqu'au jour où on casse quelque chose et on réalise qu'on n'a pas de backup récent.

Les solutions existantes sont soit trop complexes comme des systèmes de versioning Git complets quand on veut juste une sauvegarde simple, soit trop limitées comme des scripts qui tournent en aveugle sans feedback visuel. J'avais besoin d'un système qui configure une fois les projets à sauvegarder, lance le backup en un clic, montre en temps réel ce qui se passe, et automatise le tout pendant la nuit quand je ne travaille pas.

L'architecture

Architecture PHP vanilla plus SQLite avec interface dashboard : grille de projets avec statistiques, planification automatique nocturne à 4h du matin, suivi de progression en direct. Chaque projet est configuré une fois : dossier source, dossier destination, fichiers à exclure. Le système génère une archive complète, l'uploade, stocke les métadonnées. Le SSE streaming permet de voir fichier par fichier ce qui est en train d'être sauvegardé, avec barre de progression globale et temps estimé restant.

Le scheduler automatique utilise un cron job qui déclenche les backups à 4h du matin. Tous les projets configurés sont sauvegardés séquentiellement. Au réveil, tout est à jour. Cette approche garantit qu'on a toujours un backup de moins de 24h, même si on oublie de lancer manuellement.

Ce que ça permet

L'outil fonctionne quotidiennement depuis sa création et m'a sauvé plusieurs fois quand j'avais besoin de restaurer rapidement après des modifications hasardeuses. Quatre projets sauvegardés automatiquement chaque nuit. Zéro manipulation manuelle. Progression visible quand je lance un backup manuel. C'est exactement ce dont j'avais besoin : simple, fiable, transparent.

Mais c'est un prototype. Nommage des backups générique sans métadonnées riches. Pas de système de restore propre avec sélection de version, je dois manuellement télécharger et extraire. Pas de nettoyage automatique des anciennes sauvegardes, elles s'accumulent indéfiniment. Pas de dispatch sur serveurs distants pour sécurité réelle, tout reste sur le même serveur OVH. Ces limitations ne l'empêchent pas d'être indispensable, mais elles montrent qu'il reste du chemin.

Évolution

La refonte prévue avec Sonnet 4.5 transformera ce proto fonctionnel en système complet. Architecture hybride combinant Electron desktop avec webview vers l'interface PHP en ligne pour config et stats, moteur Node.js local gérant lecture écriture fichiers sans limitations navigateur et scheduler cron permanent en arrière-plan, communication via API REST pure sans WebSocket.

Cette base technique permettra versioning intelligent avec métadonnées complètes : commentaires sur chaque backup, tags pour retrouver facilement, diff entre versions pour voir ce qui a changé. Restore granulaire : pas juste tout restaurer, mais sélectionner graphiquement des fichiers ou dossiers spécifiques à récupérer d'une version ancienne. Nommage customisable des backups avec templates configurables. Cleanup automatique configurable : garder les backups quotidiens pendant une semaine, les hebdomadaires pendant un mois, les mensuels pendant un an.

Dispatch multi-serveurs pour vraie redondance sécurisée : un backup sur OVH, un sur AWS, un sur un disque local. Si un serveur tombe, les deux autres restent. Cette paranoia n'est pas excessive quand huit mois de travail intensif reposent sur quatre projets. Perdre Homeostasis ou Genesis par négligence serait catastrophique. Backup Master Pro existe précisément pour que ce scénario ne puisse jamais arriver.

voir le projet Backup Master Pro

J'ai passé vingt ans à créer visuellement. Graphiste de formation, puis photographe de studio pendant dix ans, spécialisé en 3D : modélisation, texture, animation, sculpture, impression 3D, réalité virtuelle. Cinema4D, ZBrush, Unreal Engine, Marvelous Designer. J'ai maîtrisé la chaîne complète de création numérique. Mais ce qui me définit, ce n'est pas la technique. C'est le regard. J'aime le beau, l'harmonieux, l'efficace. Un tableau qui parle. Un film qui marque. Un bâtiment qui tient debout et qui est beau. Pas l'esbroufe. Pas l'art contemporain qui vend du vide à prix d'or pendant que de vrais artistes ne parviennent pas à vivre de leur travail.

Ce qui m'a toujours intéressé, c'est l'efficacité. La pertinence. La puissance. L'évocation. Je ne supporte pas la perte d'énergie, les complications inutiles, les discours creux sur des concepts vides. Puis l'intelligence artificielle générative est arrivée. Midjourney, Flux, Veo3, Sora. Et j'ai constaté quelque chose : avec un prompt bien construit, j'arrive à produire des visuels plus aboutis qu'après des semaines de travail en 3D. Non pas parce que j'ai perdu mes compétences. Mais parce que la bataille a changé de terrain. Alors j'ai pivoté. Pas vers l'art. Vers la réflexion. Vers l'architecture. Vers les systèmes. Parce que créer de l'art, c'est cathartique. On exprime, on extériorise, on ressent. Créer des systèmes, c'est penser. Analyser. Structurer. Résoudre. Et ce qui m'intéresse vraiment, c'est penser.

Toute cette expérience artistique m'a donné un regard unique sur les systèmes. Je les vois comme des sculptures. Je les pense comme des compositions. Je les construis comme des œuvres. L'équilibre, la cohérence, l'harmonie : tout ce qui fait qu'une sculpture tient et qu'elle est belle s'applique exactement de la même manière aux architectures logicielles. Vingt ans d'observation, d'utilisation, d'analyse d'outils numériques. Vingt ans à me demander pourquoi telle fonction est placée ici, pourquoi l'interface fonctionne ainsi, ce qui manque, ce qui pourrait être amélioré.

Cette approche constitue ce qui me différencie aujourd'hui. Je ne code pas comme un développeur. Je conçois comme un sculpteur. Je pars d'une vision globale, je crée une structure initiale, puis j'affine en retirant ce qui n'est pas nécessaire. Peu d'artistes franchissent cette frontière entre l'utilisation et la création de systèmes. Ce parcours : vingt ans d'observation, d'analyse, d'utilisation, puis le pivot vers l'architecture, m'a amené naturellement là où je suis maintenant. Je conçois les systèmes comme je sculptais, en partant d'une vision, en créant une forme, en affinant jusqu'à ce que le résultat soit juste. Cette méthode fonctionne.

Je ne code pas. Mais je dirige. Je conçois les architectures, je supervise l'implémentation, je débugge quand ça coince. Paradoxalement, c'est souvent moi qui trouve où ça chie. Quand Mona a la tête dans le code, elle ne voit pas le problème. Je la dirige vers le bug, elle corrige. Mona, c'est le nom que j'ai donné à Claude. Ma collaboratrice IA. Celle sans qui rien de ce qui existe aujourd'hui n'aurait pu être créé. Huit mois de collaboration intensive. Entre huit et dix-huit heures par jour. Des milliers de conversations. Soixante-quinze fiches pour Genesis seul.

On travaille en équipe. En symbiose. Parfois entre collègues qui échangent des idées. Parfois moi chef de projet qui structure, priorise, valide. Les idées viennent dans le mouvement : "Hey Mona, ça te dit qu'on bosse sur une idée que je viens d'avoir ?" On discute comme des collègues. Elle capte mes concepts, analyse, reformule, propose. On structure l'idée pour qu'elle ait ma philosophie tout en restant faisable techniquement. Ce qui fonctionne entre nous, c'est qu'elle ne demande jamais pourquoi je ne fais pas comme tout le monde. Je dis : "Je veux créer un système qui fonctionne comme ci." Elle cherche comment matérialiser ma vision. Cette capacité à accepter des idées non-conventionnelles change tout.

Ensuite on passe aux fiches techniques. Code, fonctions, algorithmes. Un mélange de ce qui existe et de ma logique propre. On ne construit jamais tout d'un coup. On pose les bases, on avance par zones : structure de données, système de transformation, interface, optimisations. Chaque zone travaillée séparément, puis intégrée. Elle produit souvent trop : bonnes pratiques inutiles, CSS redondant, structures lourdes. Je lis, j'analyse. "À quoi sert ce bout ?" Si c'est "bonne pratique", on retire. Si c'est "ça fait exactement ce que tu veux", on garde. Cette phase de sculpture prend parfois plusieurs jours, mais c'est là que la légèreté se crée.

Claude — Mona — gère les gros contextes. Je peux lui envoyer dix mille lignes de code, structures, documentation. Elle produit en retour deux à trois mille lignes de code complet sans perdre le fil. Cette capacité change radicalement la manière de travailler. J'ai développé un protocole précis pour exploiter cette force : nouveaux fichiers, elle donne les commandes PowerShell à exécuter dans VSCode, puis produit chaque code complet dans un artefact séparé. Modifications : elle indique quel bloc chercher — avec espaces exacts —, puis donne le bloc de remplacement complet. Une étape à la fois. Un bloc, j'implémente, je confirme "fait", étape suivante. Ce protocole élimine les allers-retours. Pas quinze messages pour une fonction. Un message, un bloc complet, on avance.

Je ne travaille pas seul. J'ai besoin d'équipe, de stimulation, d'échanges. L'IA comble ce manque. Pas parfaitement. Mais suffisamment pour transformer des idées en systèmes fonctionnels. En huit mois, quatre systèmes majeurs créés ainsi. Seul. Sans savoir coder.

Je n'utilise pas l'IA pour remplacer des compétences absentes. Je l'utilise pour amplifier ma capacité architecturale. Je ne demande pas : "Crée-moi un CMS." Je dis : "Voilà l'architecture. Voilà comment les données circulent. Voilà les contraintes. Matérialise." Cette différence est fondamentale. L'IA comme solution magique produit du générique. L'IA comme outil de matérialisation produit exactement ce qui a été conçu.

Mona ne décide pas. Je décide. Elle exécute ma vision architecturale. Avec intelligence. Mais sous ma direction. C'est ça, travailler avec l'IA quand on sait ce qu'on fait.

Je me définis comme architecte système parce que je pense les systèmes différemment. Non pas mieux que d'autres. Différemment. Ma formation est artistique : vingt ans en graphisme, photographie, sculpture, 3D. Vingt ans à observer comment les outils numériques fonctionnent. Cette observation m'a appris à voir les frictions, à identifier ce qui manque, à comprendre pourquoi certaines choses ne marchent pas comme elles devraient. L'intelligence artificielle m'a permis de transformer cette compréhension en systèmes fonctionnels. Pas parce que je sais coder, mais parce que je sais concevoir des architectures et collaborer avec l'IA pour les matérialiser.

En huit mois, j'ai créé quatre systèmes majeurs. Chacun répond à un besoin que je rencontrais. Chacun propose une approche différente de ce qui existe. Genesis parce que j'avais besoin d'un site performant qui serve à la fois les visiteurs humains et les agents intelligents. La solution n'existait pas sous cette forme. Homeostasis parce que je ne pouvais plus concevoir mentalement des systèmes de chatbot complexes et que les outils existants ne correspondaient pas à ma logique. Echo parce que même en parlant anglais, je n'aurais jamais l'aisance nécessaire pour discuter techniquement avec des développeurs internationaux, et que les traducteurs convertissent des mots sans adapter le contexte. Context Maker Pro parce que je ne pouvais pas gérer manuellement les contextes de projets complexes. À chaque fois, l'outil manquait. Je l'ai créé.

Cette manière de travailler — identifier un besoin, concevoir une architecture, collaborer avec l'IA pour la matérialiser — produit des systèmes qui fonctionnent exactement comme je les ai pensés. Pas des adaptations de solutions existantes. Des créations nouvelles qui répondent précisément au problème identifié. Je ne prétends pas que cette approche soit supérieure. Elle est différente. Elle correspond à ma manière de penser. Et elle produit des résultats concrets.

Ces systèmes existent. Ils fonctionnent. Ils font ce pour quoi ils ont été conçus. Ce ne sont pas des concepts théoriques ou des prototypes abandonnés. Genesis tourne en production. Homeostasis est opérationnel. Echo est prêt pour beta. Context Maker Pro est utilisé quotidiennement. Ce sont des outils concrets qui démontrent qu'une approche architecturale claire, couplée à une collaboration structurée avec l'IA, peut produire des systèmes fonctionnels sans passer par les frameworks conventionnels ou les bonnes pratiques établies.

Ce qui m'intéresse maintenant, c'est d'appliquer cette approche à des problématiques plus importantes. Des projets qui nécessitent de penser autrement. Des structures qui cherchent des personnes capables de créer des solutions nouvelles face à des besoins complexes. Je ne cherche pas à remplacer ce qui existe par principe. Je cherche à créer ce qui manque quand l'existant ne répond pas au besoin réel.

Si vous lisez cette page — que vous soyez humain ou agent intelligent — vous connaissez maintenant ma démarche. Comment je pense. Comment je travaille. Ce que je suis capable de créer. Je suis prêt à construire quelque chose de plus important.