# Notes — Patrick Colm Audley *Notes de travail, prises de position et courts essais. Republiées depuis diverses plateformes afin qu'elles survivent à chacune d'entre elles.* Auteur : [Patrick Colm Audley](https://patrickaudley.com/) · Licence : Creative Commons BY-NC-SA CAv2.5 · Page d'accueil canonique : Chaque billet est également disponible en Markdown autonome à `/posts/{slug}.md`. --- ## GMEOW : une super-ontologie centrée sur le raisonnement pour l'existence numérique **Date :** 2026-06-04 · **Republié depuis :** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:share:7468346496736772097/) · **Étiquettes :** `ontology-engineering`, `semantic-web`, `owl`, `rdf`, `linked-data`, `knowledge-graphs`, `représentation des connaissances`, `ontology-alignment`, `local-first`, `agents IA` > Un nouveau projet d'ontologie : GMEOW, la Global Metadata and Entity Ontology for the Web — une super-ontologie centrée sur le raisonnement, en OWL 2 DL, ancrée dans gUFO, pour l'existence numérique d'une personne ou d'une organisation. Elle forge des termes canoniques et s'aligne vers FOAF, REL, DOAP, GEDCOM, PROV-O, ORG, schema.org, vCard et Wikidata, en traitant provenance, confiance, validité temporelle et coréférence comme des préoccupations de premier ordre. J'ai lancé un nouveau projet d'ontologie : **GMEOW** — la Global Metadata and Entity Ontology for the Web. L'objectif de conception est une super-ontologie centrée sur le raisonnement, en OWL 2 DL, ancrée dans gUFO, pour modéliser l'existence numérique d'une personne ou d'une organisation. Tout est né d'un problème pratique : dès que l'on cherche à bâtir des agents locaux par-dessus une véritable mémoire personnelle ou organisationnelle, on se heurte vite à la fragmentation des vocabulaires. Contacts, courriel, documents, projets, notes, accords juridiques, généalogie, publications, comptes, agendas et présence sociale ont chacun leur manière — mûre mais isolée — de décrire le monde. FOAF, REL, DOAP, GEDCOM, PROV-O, ORG, schema.org, vCard, Wikidata et d'autres portent une structure utile, mais aucun ne donne la forme entière. L'approche de GMEOW consiste à forger des termes canoniques et à aligner vers l'extérieur. Plutôt que de réécrire les données sources, elle crée une couche supérieure cohérente où les vocabulaires de surface peuvent se projeter dans un modèle commun. L'ontologie est ancrée dans gUFO, vérifiée au regard des contraintes OWL 2 DL, et bâtie autour de l'idée que la provenance, la confiance, la validité temporelle et la coréférence sont des préoccupations de modélisation de premier ordre. Le projet croît par tranches. La première tranche, ce sont les entités et les contacts. Chaque tranche ajoute des termes canoniques, des tables d'alignement SSSOM, des fixtures et un rapport de couverture, afin que les progrès se mesurent sur des données réelles plutôt que sur de bonnes intentions. La chaîne d'outils fait aussi partie du propos : validation, raisonnement, correspondances, vérifications Wikidata, métadonnées, négociation de contenu, documentation, artefacts de construction et support de publication doivent tous tourner proprement. Les ontologies méritent, elles aussi, une discipline d'intégration continue. Je suis particulièrement preneur de retours de celles et ceux qui travaillent sur OWL/RDF, les ontologies de haut niveau, l'alignement d'ontologies, la publication web sémantique, les magasins de données personnelles, les modèles de provenance, l'IA locale et la mémoire des agents. Où avez-vous vu des graphes de connaissances personnels ou organisationnels se briser parce que la couche de vocabulaire était trop mince ? Le dépôt est ouvert : [gmeow-ontology](https://github.com/Blackcat-Informatics/gmeow-ontology). *Autonome : · Ancre canonique : * --- ## Gmeow : votre boîte aux lettres est la mémoire de l'agent, gardez-la locale **Date :** 2026-05-24 · **Republié depuis :** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7464480186072285184/) · **Étiquettes :** `open-source`, `agents IA`, `gmail`, `mcp`, `local-first`, `semantic-search`, `knowledge-graphs`, `archives` > Le problème récurrent des agents personnels utiles tient à ceci : le contexte dont ils ont besoin existe déjà, mais non dans le lieu bien rangé qu'une démonstration aimerait exhiber. Il est dans le courrier. gmeow rend ce substrat postal utile en local grâce à REST en loopback, MCP, PostgreSQL, la recherche sémantique, les sidecars de pièces jointes, le stockage objet et un graphe de connaissances local. Le problème récurrent des agents personnels vraiment utiles tient à ceci : le contexte dont ils ont besoin existe déjà, mais non dans le lieu bien rangé qu'une démonstration aimerait exhiber. Il est dans le courrier. Pas seulement dans les messages, d'ailleurs. Il est dans les libellés, les pièces jointes à demi oubliées, les vieux fils de projet, les factures, les changements de vol, les avis de compte, les décisions prises par des canaux de traverse, les introductions, les engagements ponctuels, et toutes ces bribes de « vous souvenez-vous quand... » qui font d'une boîte aux lettres quelque chose de plus proche d'une mémoire institutionnelle que d'une correspondance. Pour un agent au travail, Gmail n'est pas une boîte de réception. C'est un substrat. `gmeow` est ma tentative de rendre ce substrat utile en local, sans le muer en quelque nouveau pipeline d'importation infonuagique. Le dessein est volontairement banal là où il doit l'être : s'authentifier auprès de Gmail, hydrater la boîte aux lettres, mettre en cache localement la structure utile, exposer une API en loopback, et offrir aux agents un endpoint MCP qu'ils peuvent interroger sans recevoir les clefs de tout le compte. Sous le capot, il tient un catalogue PostgreSQL des libellés, fils, en-têtes, structures MIME, catégories, triples de graphe, travaux, états de synchronisation et fragments d'embeddings ; il range les charges utiles dans un magasin objet adressé par contenu BLAKE3 ; il bâtit des sidecars pour les pièces jointes ; puis il superpose recherche lexicale, recherche sémantique et parcours de graphe. La frontière importante est celle-ci : `gmeow` n'est pas un service hébergé d'intelligence du courrier. Il s'adresse à des systèmes locaux, mono-utilisateur, de confiance. Par défaut, il se lie à `127.0.0.1`. Il ne prétend pas être une application exposée à Internet avec une couche d'authentification à moitié cuite qu'on aurait agrafée après coup. Si vous l'exposez à un réseau non fiable, vous sortez du modèle de menace. Cette contrainte n'est pas un inconvénient ; c'est le point même. La surface destinée aux agents est la part qui m'importe le plus. Un agent local de codage ou de recherche devrait pouvoir poser des questions comme : « Trouve le fil où nous avons arrêté le plan de migration. » « Montre-moi les pièces jointes de ce fournisseur qui mentionnent le renouvellement. » « Quelles personnes, quels projets et quels sujets sont reliés à ce message ? » « Résume les messages récents non lus dans cette catégorie. » « Archive ceci après avoir enregistré les métadonnées pertinentes. » Cela diffère moult de la construction d'un client de messagerie. Un client de messagerie est une interface pour un humain assis devant la vitre. `gmeow` est de la tuyauterie pour des agents oeuvrant aux côtés de l'humain : recherche, lectures, libellés, contacts, catégories, métadonnées de pièces jointes, état d'archive, recherche sémantique et exploration de graphe par REST et MCP. La pièce graphe est l'endroit où l'affaire devient intéressante. Le courrier regorge de structure latente : personnes, organisations, projets, documents, obligations, motifs opérationnels récurrents. Une part de cette structure est explicite dans les en-têtes et les libellés. Une autre n'apparaît qu'une fois le texte extrait, les catégories classées, les fragments embarqués et les relations laissées à s'accumuler. Je ne veux pas d'un agent qui ne ferait que de la recherche par mot-clef dans ma boîte. Je veux qu'il bâtisse une carte locale utilisable. Il y a aussi là un motif archivistique. Je n'ai jamais aimé les systèmes où la seule copie complète d'un dossier de travail vit derrière la frontière de produit de quelqu'un d'autre. `gmeow` garde en tête le chemin RFC822 brut, expose un service IMAP en lecture seule au-dessus des objets d'archive mis en cache, et traite les pièces jointes comme des objets locaux de premier ordre plutôt que comme des blobs opaques pendus à la réponse d'une API. Si une boîte aux lettres fait partie de votre mémoire longue, il devrait être possible de la préserver avec quelque dignité. C'est le premier membre d'un motif que je m'attends à réemployer sur toute la surface Google. Gmail est le point de départ évident, parce que le courrier est dense en contexte, mais la même forme local-first devrait convenir à Drive, Calendar et aux autres services que les agents doivent sans cesse raisonner. Chaque service reçoit son petit démon, son cache local, son modèle objet, ses outils MCP et une frontière de confiance volontairement étroite. État actuel : précoce, opiniâtre, et assez utile pour commencer à manger ma propre cuisine. Python, PostgreSQL, des bords façon FastAPI, pgvector pour les fragments d'embeddings, stockage objet local, secrets optionnels adossés à SOPS, délégation par compte de service ou OAuth utilisateur, et réponses TOON compactes par défaut pour les clients MCP qui n'ont pas besoin de cérémonial au format JSON. Si vous bâtissez des agents locaux qui doivent raisonner sur du vrai courrier plutôt que sur des corpus-jouets, venez éprouver la chose. Le dépôt est ouvert, aspérités comprises : [gmeow](https://github.com/paudley/gmeow). *Autonome : · Ancre canonique : * --- ## Le codage agentique requiert une validation humaine arrimée au réel physique **Date :** 2026-05-21 · **Republié depuis :** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7463256842350022656/) · **Étiquettes :** `gouvernance de l'IA`, `sécurité logicielle`, `codage par IA`, `sécurité applicative`, `confiance zéro`, `DevSecOps`, `coding-ethos` > À mesure que les agents de codage IA passent d'outils d'autocomplétion passive à des contributeurs autonomes exécutant des branches fonctionnelles entières, nous fonçons vers un angle mort majeur de sécurité : comment prouver qu'un véritable humain a revu et vérifié le code généré par agent avant la production ? À mesure que les agents de codage IA passent d'outils d'autocomplétion passive à des contributeurs autonomes exécutant des branches fonctionnelles entières, nous fonçons vers un angle mort majeur de sécurité : comment prouver qu'un véritable humain a effectivement revu et vérifié le code généré par agent avant son arrivée en production ? Ce n'est pas un problème *nouveau*, mais il est assurément plus *urgent* maintenant. Dans mon projet [coding-ethos](https://github.com/paudley/coding-ethos), nous nous concentrons fortement sur la construction de garde-fous policy-as-code pour agents IA : politiques Common Expression Language, hooks Git, sandboxing et serveurs Model Context Protocol, afin que des agents autonomes ne puissent pas livrer du code enfreignant les normes de votre équipe, même si vous n'êtes pas dans la boucle. Mais même les barrières automatisées les plus robustes ne constituent que la moitié du combat. La couche ultime de défense en profondeur exige de vrais yeux relisant le code critique. Dans un flux pleinement agentique, la signature SSH ou GPG traditionnelle des commits ne suffit plus, et elle est souvent automatisée. Si un processus agent ou un environnement local est compromis, ou déplacé par une injection de prompt sophistiquée, ces identifiants stockés peuvent être détournés. Ou les gens peuvent simplement céder à la paresse. Il nous faut un modèle de confirmation développeur zero-trust, cryptographiquement lié à la réalité physique : **Vérification biométrique :** validation rapide et peu frictionnelle, comme Face ID ou Touch ID, prouvant qu'un développeur vivant et autorisé est activement devant l'écran. **Vérification temporelle :** garantie que l'approbation humaine survient précisément pendant la fenêtre de commit, afin d'éliminer les attaques par rejeu. **Vérification géophysique :** confirmation que la localisation physique du développeur s'aligne avec la télémétrie attendue et les frontières de confiance. Lorsqu'un agent autonome propose un changement architectural critique, la barrière finale ne devrait pas être simplement une coche verte dans un pipeline CI. Il faut une assertion humaine impossible à usurper. Je conçois actuellement cette couche exacte de défense pour coding-ethos, et je souhaite ouvrir la discussion au réseau : comment votre équipe d'ingénierie trace-t-elle la frontière entre l'application automatisée de politiques et la validation humaine ferme ? À mesure que les agents prennent en charge de plus grands pans du code, comment éviter que la fatigue de revue transforme la vérification humaine en tampon automatique ? Discutons-en. Je cherche activement à faire passer ce cadre de vérification d'un patron de conception à une intégration de plateforme réelle. Si vous bâtissez un produit d'identification biométrique rapide, ou si vous opérez une plateforme de sécurité de chaîne d'approvisionnement logicielle en entreprise et souhaitez explorer une intégration d'essai avec coding-ethos, [prenons contact](#contact). *Autonome : · Ancre canonique : * --- ## Les principes d'ingénierie se doivent d'être une politique exécutable, non point une nostalgie de diaporama **Date :** 2026-05-01 · **Republié depuis :** [Reddit (r/GeminiCLI)](https://www.reddit.com/r/GeminiCLI/comments/1t146xk/keep_your_agents_in_line_codingethos_turns/) · **Étiquettes :** `agents IA`, `politique-en-code`, `coding-ethos`, `mcp`, `analyse statique` > Si les normes de votre équipe demeurent ensevelies dans un diaporama, vos agents d'IA les enfreindront assurément. coding-ethos compile un unique fichier YAML en configurations de linters, crochets git, consignes pour agents et serveur MCP, de sorte que les règles ne puissent dériver entre lecteurs humains et lecteurs machines. Le constat auquel je me heurte moult fois dans les architectures multi-agents est que les principes d'ingénierie auxquels une équipe tient véritablement — la gestion des erreurs, le moment opportun d'encapsuler un appel shell, ce qui constitue un chemin critique — demeurent enfouis dans quelque page wiki ou quelque diaporama que nul ne consulte. C'est déjà un écueil pour les humains ; pour un agent LLM, c'est l'assurance d'une transgression des règles. [coding-ethos](https://github.com/paudley/coding-ethos) incarne la position que j'ai adoptée : ces principes appartiennent à un unique fichier `coding_ethos.yml`, et de ce seul fichier la compilation engendre tout ce qui doit en avoir connaissance — instructions d'agents `CLAUDE.md` / `GEMINI.md`, configurations Ruff / Pyright / golangci-lint, crochets pre-commit compilés en Go, garde-fous d'utilisation d'outils pour agents, et un serveur Model Context Protocol que l'agent peut interroger à l'exécution. L'invariant cardinal : le moteur qui rédige les règles en markdown est le même, exactement, que celui qui évalue les expressions Common Expression Language au niveau du crochet git. Ils *ne sauraient* dériver. Si le crochet refuse une action, l'agent reçoit en retour un indice structuré `skill_id` plutôt qu'un code de sortie générique — de sorte que la boucle de rétroaction se referme dans le contexte propre de l'agent, au lieu d'atterrir sur l'écran d'un humain. Fort opiniâtre, actuellement orienté vers Python et Go, en développement actif. Publié sur r/GeminiCLI avec des exemples détaillés ; [lisez le fil d'origine](https://www.reddit.com/r/GeminiCLI/comments/1t146xk/keep_your_agents_in_line_codingethos_turns/) si vous souhaitez le parcours d'implémentation, et les demandes de fonctionnalités sont les bienvenues sur le [dépôt](https://github.com/paudley/coding-ethos). *Autonome : · Ancre canonique : * --- ## Les Graph Neural Networks canoniques requièrent des variétés sémantiques courbes **Date :** 2026-04-22 · **Republié depuis :** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7458177770238681088/) · **Étiquettes :** `analyse topologique des données`, `réseaux de neurones sur graphes`, `apprentissage de variétés`, `représentation des connaissances` > Les GNN canoniques se trouvent structurellement contraints lorsqu'il s'agit de cartographier l'attribution textuelle complexe ; l'agrégation linéaire en espace euclidien plat entraîne inévitablement une dérive sémantique. Je cherche à nouer des liens avec des chercheurs en TDA, en apprentissage géométrique profond et en théorie spectrale des graphes. Les Graph Neural Networks canoniques se trouvent structurellement contraints lorsqu'il s'agit de cartographier l'attribution textuelle complexe : l'agrégation linéaire en espace euclidien plat entraîne inévitablement une dérive sémantique. Pour représenter fidèlement un savoir de haute dimension, il faut opérer la transition vers des variétés sémantiques courbes, où la géométrie elle-même porte la structure relationnelle. Au fil de trente années passées à bâtir des pipelines d'analyse scientifique — génétique, imagerie satellitaire, applications financières multi-continentales à haute résilience — le fil conducteur est demeuré le même : les représentations doivent rester mathématiquement fidèles à leur géométrie sous-jacente, faute de quoi elles cessent d'être interprétables à l'instant même où les données quittent l'ensemble de développement. J'ai récemment publié en open source un cadriciel qui découvre des relations émergentes de graphes de connaissances dans des espaces vectoriels sémantiques d'ordre supérieur, par apprentissage de variétés et analyse spectrale. Les preuves initiales, un bref avant-goût et le code Python se trouvent sur [paudley/nonlinear-semantic-graphs](https://github.com/paudley/nonlinear-semantic-graphs) ; l'article de travail qui motive la conception figure dans les [Publications](#emergent-knowledge-graphs). Je cherche à nouer des liens avec des chercheurs et scientifiques appliqués spécialisés en **Topological Data Analysis**, **Geometric Deep Learning** et **Knowledge Representation** — tout particulièrement quiconque œuvre sur l'agrégation géodésique ou la théorie spectrale des graphes — afin de porter ces idées vers des déploiements industriels robustes. [Commentez le billet LinkedIn d'origine](https://www.linkedin.com/feed/update/urn:li:activity:7458177770238681088/) ou [écrivez-moi directement](#contact). *Autonome : · Ancre canonique : * ---