Quentin G.

Comment conjuguer : données, applications, logique métier, et agents IA. Tu arrives à créer des agents IA en 2 min avec n8n ? Mais ils ne sont pas branchés aux données de ton entreprise ni à la réalité opérationnelle (process et flux). Pour récapituler notre logiciel : 1- Interfaces pour modéliser la logique métier. 2- Librairie d’agents nativement connectés à vos données. 3- 500 connecteurs logiciels pour unifier vos sources. 4- Workflow builder no-code / low-code pour automatiser les process. 5- 500 APIs pour consommer les données et services. 6- Interface de pilotage et de monitoring de l’ensemble. bonus : hébergement souverain, inférence de l’IA en France, et développement d’intégrations sur mesure. Pourquoi est ce qu’on à développé cette plateforme ? Voici quelques problèmes qu’on à rencontrés lorsqu’on intègre l’IA : - Données éparpillées entre logiciels et bases de données. - Aucune modélisation fiable et vivante des flux métier. - Très difficile de connecter l’IA à la réalité opérationnelle (et donc IA inutile). exemple : si je veux avoir un agent branché sur mes données (type : base de données, flux métiers, documentation), il faut que j’arrive à récupérer ces données à travers différents logiciels et ensuite que je développe des pipelines pour récupérer et formater les données pour l’IA (gros travail) L’ontologie permet justement de faciliter l’ensemble de ce processus. En quoi c’est différent d’un n8n / make ? n8n permet d’automatiser avec une richesse dans les abstractions (type agents), mais ne permet pas en amont de décrire les flux et donc d’avoir des workflows qui s’integrent à la réalité. Dans la démo vidéo : 1. Je crée le flux d’une pipeline de vente (de l’apparition d’un prospect, à l’envoie de la proposition). 2. Je teste un agent IA, et il a automatiquement accès au contexte de la pipeline (oui pas besoin de développer de rag, des outils dédiés, de tout mettre tous les éléments dans le prompt, etc). 3. Puis je connecte un google sheet qui liste mes prospects. 4. J’utilise ce google sheet comme base de données, pour calculer quelles sont les entreprises les plus intéressantes à cibler, via un workflow d’automatisation (qui utilise notamment un agent IA). 5. Ensuite je peux piloter et monitorer l'ensemble. si tu es intéressé par notre logiciel et notre accompagnement, tu peux prendre un rdv avec moi (sur mon site dans ma bio). youtu.be/3p4JivtmiIA

Je te décrypte l’attaque brutale, détectée hier, d’une des technos IA les plus utilisées (que j’utilise moi-même) : LiteLLM. Ce n’est pas une attaque par prompt injection, Ce n’est pas une attaque par brute force, C’est un simple pip install. Et non, on ne parle pas d’un faux package typo-squatté. On parle du vrai litellm sur PyPI, un projet à plus de 96 millions de téléchargements mensuels, devenu critique dans l’écosystème IA. (note : le nombre de téléchargements n'est pas égal au nombre d'utilisateurs uniques, mais ça nous indique l'ampleur du problème). Pourquoi on utilise liteLLM ? Il permet d’unifier, proxyfier et router les appels vers plusieurs modèles et plusieurs providers (c’est précisément pour ça qu’il est autant utilisé dans des stacks IA d’entreprise). Les versions compromises connues : 1.82.7 et 1.82.8. le code malveillant s'exécute automatiquement au démarrage de python via un fichier .pth (sans même nécessiter un import explicite de litellm). Concrètement, le payload cherche à aspirer tout ce qui à de la valeur dans une stack moderne : variables d'environnement, clés API, credentials AWS / GCP / Azure, clés SSH, config et tokens k8s, mdp, configs docker, historique shell. le détail presque ironique : l'attaque aurait pu rester invisible plus longtemps, mais elle a été repérée parce qu'un bug dans le malware a provoqué un fork bomb, l'article de Futursearch explique l'avoir découverte via une dépendance transitive par un plugin MCP dans cursor. Et là, le sujet devient beaucoup plus large que LiteLLM. La compromission s'inscrit dans une chaîne plus vaste possiblement liée à l'incident Trivy, lui même consécutif à une compromission antérieure. Donc oui : on assiste en direct à un effet domino entre scanner de sécurité, CI/CD, tokens de publication, registries, plugins, runners, images et environnements cloud. Heureusement, que j'utilisais l'image docker officiel : ghcr.io/berriai/litellm qui n'est pas affectée par cette compromission. Sans évoquer le fait que LiteLLM était certifié SOC 2... Si vous utilisez liteLLM, voici ce qu'il est recommandé de faire : 1. Vérifier si 1.82.7 ou 1.82.8 a été installée quelque part (pip show litellm, CI, images Docker, builds récents). 2. Chercher la présence de litellm_init.pth dans les environnements Python concernés. 3. Considérer tous les secrets présents sur les machines touchées comme compromis, puis les faire tourner immédiatement. 4. Purger les caches pip / uv pour éviter une réinstallation depuis un artefact local. 5. Auditer les sorties réseau vers models.litellm.cloud et chercher une éventuelle persistance type ~/.config/sysmon/sysmon.py / sysmon.service. 6. Si Kubernetes était accessible, auditer le cluster pour des accès suspects aux secrets et des pods du type node-setup-*. 7. Pinner LiteLLM sur 1.82.6 ou sur une release ultérieure explicitement validée comme sûre.

rejoins notre communauté IA (+4700 membres) : skool.com/ai-builder-289…

La liste des technos récentes dans l’écosystème IA open-source, qui méritent une lecture (à mon avis)... 1. Autoresearch de Karpathy 2. Deep Agents de LangChain 3. Nemotron de NVIDIA 4. HyperAgents 5. λ-RLM 6. OpenClaw 7. OpenShell de NVIDIA Pour plus de détails, 1. Autoresearch, c’est l’idée d’un petit labo de recherche IA autonome : On donne à un agent un mini setup réel d’entraînement de LLM, il modifie le code, lance un entraînement, mesure l’effet de la modification sur le résultat, conserve ou rejette l’essai, puis recommence. C’est un paradigme intéressant à creuser, et potentiellement à appliquer à d’autres champs que l’entraînement de LLMs, ou plus largement à l’auto-amélioration de systèmes IA. Note : beaucoup de nos clients, pensent qu'en donnant de la data à un LLMs celui-ci apprends à l'inférence, mais justement non, on utilise surtout des leviers de context engineering, de mémoire, d’outils et de workflow, mais le modèle ne se réentraîne pas tout seul. Le projet de Karpathy nous fait une démonstration concrète de la manière dont on pourrait avoir des IA qui s’améliorent de façon autonome. 2. Deep Agents de LangChain C’est intéressant pour les développeurs qui souhaitent créer des agents capables de gérer des tâches longues et complexes. C’est un harness qui combine : de la planification, un système de fichiers virtuel, des sous-agents et de la gestion du contexte, autrement dit, une proposition d’ingénierie pour des agents durables. 3. Nemotron de NVIDIA Ce n’est pas seulement une famille de LLM : c’est plus largement une famille de modèles ouverts, de datasets et de technologies conçue pour construire des systèmes IA agentiques spécialisés. 4. Hyperagents L’idée de systèmes qui s’améliorent eux-mêmes, avec un angle plus général de self-improvement que le seul entraînement de modèles. Le papier introduit des agents auto-référentiels qui fusionnent l’agent de tâche et le méta-agent dans un seul programme éditable, avec une procédure d’amélioration qui peut être elle-même modifiée. 5. λ-RLM / The Y-Combinator for LLMs Le papier est une proposition de recherche sur le raisonnement long contexte, en remplaçant la génération libre de code récursif par un runtime fonctionnel fondé sur le λ-calcul, avec des opérateurs structurés comme SPLIT, MAP, FILTER, REDUCE, l’intérêt est double : des garanties formelles que les approches libres n’offrent pas forcément, et des résultats empiriques solides sur des tâches de raisonnement à long contexte. 6. OpenClaw Ce qui m’intéresse ici, ce n’est pas tant l’assistant en lui-même que l’approche self-hosted, multi-canaux et orientée action, et la brique d'agents qui planifient, exécutent et itèrent jusqu'à l'accomplissement de l'objectif (persistance). 7. OpenShell de NVIDIA (je vous présenterai cette techno dans une prochaine vidéo sur ma chaîne youtube).

J’ai benchmarké Ollama vs vLLM sur un H100, et l’écart est franchement massif. (note : ils permettent d'exécuter des LLMs sur votre infra), Le benchmark a été exécuté sur le même GPU : - NVIDIA H100 80 GB HBM3 - un seul backend à la fois - 100 requêtes identiques + 20 warmup - concurrence = 3 - timeout = 120 s - streaming SSE activé - seed fixe + température 0 pour rendre le run déterministe - monitoring GPU actif pendant le test Sur ce run : - fiabilité : 100 % pour vLLM vs 99 % pour Ollama - latence moyenne : 3,3 s vs 12,9 s - latence médiane : 2,9 s vs 11,9 s - P95 latence : 6,7 s vs 20,2 s - speedup médian : 4,5x - speedup moyen : 5,3x Et surtout : - TTFB moyen : 1,1 s pour vLLM vs 9,3 s pour Ollama - TTFB médian : 0,94 s vs 9,3 s - 84 % des requêtes vLLM passent sous 2 s de TTFB - 0 % des requêtes Ollama passent sous 2 s Le point le plus important : le premier token, vLLM affiche du texte très tôt Ollama fait attendre longtemps avant d’émettre quoi que ce soit ce qui à un impact important côté UX. Une vidéo pour vous montrer comment installer et exploiter vLLM ?

La capacité distinctive de notre porte-avions, ce sont ses catapultes. En dehors des US, nous sommes les seuls à disposer d’un porte-avions opérationnel équipé de ce système. Et ça change tout. Les catapultes permettent de faire décoller des avions plus lourds, donc mieux armés, avec davantage de carburant ou de capacités embarquées (rafale marine mais aussi Hawkeye). Sans parler du fait qu’il permet de maintenir des avions de chasse en opération sur une vaste zone, sans dépendre de bases terrestres. Donc précisément ce qui lui donne une valeur stratégique majeure.

@VictorLignel @alexteillet on a déjà rdv vendredi ahah...

@alexteillet @Quentin_Mkting Quentin, dispo mp?

je cherche un presta / agence sérieux qui fait du design de présentation commerciale / plaquette ?

Et si des agents IA tentaient réellement de hacker votre application ? Explorons un pentester autonome qui exploite les vulnérabilités... Le projet en question : Shanon de keygraph. Note : je l’ai testé avec des modèles open-source sur mes GPUs plutôt qu’avec l’API d'Anthropic, La plupart des scanners de sécurité font une chose : signaler des vulnérabilités potentielles. Le problème ? Beaucoup de faux positifs. Shannon prend l’approche inverse : preuve par exploitation. Concrètement, l’agent se comporte comme un pentester humain : - Il lit le code source pour comprendre la logique de l’application - Cartographie les routes, API et mécanismes d’authentification - Lance des phases de reconnaissance (scan réseau, discovery, fingerprinting) - Identifie les vecteurs d’attaque potentiels - Exécute de vrais exploits (SQL injection, XSS, SSRF, auth bypass…) - Génère un rapport complet avec PoC reproductible Tout cela de manière autonome. Quelques résultats intéressants : 96.15 % de réussite sur le benchmark XBOW +20 vulnérabilités critiques trouvées sur OWASP Juice Shop en une exécution Des outils comme Shannon ouvrent une nouvelle direction : le pentest continu et automatisé dans le pipeline de développement. En pratique, cela revient à avoir une red team autonome qui teste votre application à chaque build (e.g. CI/CD). Le projet est open source si vous voulez l’expérimenter :

Dans un monde où chaque semaine on a : - Un nouveau LLM. - 5 nouveaux outils. Est-ce que la question c'est : Quel est le meilleur LLM / agent ? Ou plutôt : Comment construire le socle qui est connectable à ces agents.

Data Gouv sort son serveur MCP (la France a de l’avance sur un sujet), J’ai enregistré une vidéo pour vous expliquer le fonctionnement ... C'est quoi un MCP ? Comment connecter claude code au MCP de Data Gouv ? Les 5 outils exposés : - search_datasets : rechercher des jeux de données ; - get_dataset_info : accéder aux métadonnées d’un jeu de données ; - list_dataset_resources : lister les ressources associées ; - get_resource_info : consulter les métadonnées d’une ressource ; - query_resource_data : interroger directement certaines données ; - download_and_parse_resource : télécharger et analyser une ressource ; - get_metrics : accéder à des indicateurs d’usage. youtu.be/PNFUMFzPT2s

Comment construire le socle décisionnel de l'entreprise à l'ère de l'IA : 1. Modéliser le jumeau numérique. 2. Rendre la surface exploitable : APIs, MCP. 3. Orchestrer des automatisations. youtube.com/watch?v=wycVB2…

Comment transformer le prompting, en un problème d'optimisation programmatique... On passe tous par la même phase : - Tu écris un prompt, tu testes. - Tu changes une formulation, tu retestes. - Tu interprètes ce que le LLM a fait, tu ajustes. - Tu recommences. C’est ce que j’appelle du prompting artisanal. Le problème : - non reproductible, - non mesurable, - non scalable. Et dès que ton agent doit gérer plusieurs scénarios (cas limites, variantes métiers, exceptions), ça devient vite ingérable. L’alternative : traiter le prompt comme un objet optimisable Plutôt que d’itérer “à l’intuition”, on utilise DSPy, un framework open source qui transforme l’écriture de prompts en problème d’optimisation. Le principe est simple : 1. Tu définis une signature (entrées / sorties attendues) 2. Tu fournis un dataset (exemples représentatifs) 3. Tu définis une métrique (ce que “bon” veut dire) 4. DSPy compile et optimise la pipeline pour maximiser ta métrique Ce que ça change par rapport à l’approche classique Dans l’approche manuelle, tu passes ton temps à modifier : - La structure du prompt - La sémantique - Le contexte injecté - Les exemples …puis tu gardes “ce qui semble mieux marcher”. Avec DSPy, tu formules plutôt un objectif explicite : Mon agent doit classifier correctement 92% des tickets entrants sur 1 000 conversations historiques, avec un taux de faux positifs inférieur à 5% sur la catégorie ‘urgent’. Et ensuite, DSPy explore systématiquement l’espace des formulations/pipelines possibles pour te rendre une version optimisée,  sans que tu aies à écrire le prompt final à la main. Concrètement, les bénéfices : - Tu versionnes tes prompts comme du code (et tu peux justifier chaque changement) - Tu mesures l’impact d’une modification (prompt, contexte, modèle, etc.) au lieu de débattre - Tu peux tester un changement de LLM rapidement, sans repartir de zéro - Tu arrêtes les discussions infinies sur “le meilleur prompt” : c’est la métrique qui tranche

opus qui prend +25 minutes pour me pondre un fichier .md

l'infra est le moat. J'ai fait le choix très tôt de construire mon logiciel sur Kubernetes , et je suis convaincu des avantages tangibles. Et vous, vous êtes plutôt serverless ? Pourquoi ?

rejoins notre communauté IA (+4500 membres) : skool.com/ai-builder-289…

Un agent mal isolé peut modifier la base de données, exfiltrer des données, envoyer des mails en autonomie - ce qui rend le sandbox un pré-requis à une implémentation sérieuse (comme on le voit avec Google, Nvidia, Cloudfare). l’erreur classique : exécuter ces agents avec les mêmes privilèges que le reste de l’infra. Donc voici les avantages, et l’architecture (simplifié) qu’on a implémentée dans notre plateforme, Les points forts : 1. Sécurité drastiquement renforcée : réduction de la surface d’attaque, multi-tenant, controle de l’egress, systèmes de fichiers éphémères, gardes fous lié au ressources. 2. Monitoring natif : traçage par exécution, détection plus simple d’anomalies, tracking des logs, et surtout tout I/O devient instrumenté. 3. Scalabilité et stabilité : débit plus élevé, backpressure propre, isolation des pannes 4. Auditabilité : jobs signés, format canonique. Et l’architecture simplifiée (dans le schéma que j’ai fait) : Zone 1 - Le Control Plane : L'orchestrateur reçoit les requêtes clients (JWT/API/Workspace), applique les RLS, le RBAC, valide les inputs. Ensuite il signe cryptographiquement chaque job avant de l’envoyer au worker. Zone 2 - Exécution en Sandbox : le worker s’exécute dans un environnement isolé, sans les credentials en directs. Il ne peut accéder aux données et aux LLMs qu’en passant par l’API interne du Control Plane (qui vérifie à chaque appel que le job a bien les droits). Zone 3 - Sanbox I/O : les outils risqué type web browser, génération de code, tourne dans une sous sandbox. Les sortie réseau passent par un egress allowlist loggé. Où en est l’écosystème ? - Google lance Agent Sandbox sur kubernetes (Novembre 2025). - Nvidia publie un guide de sandboxing (février 2026). - Cloudfare Sanboxe (juin 2025). Et nous même on participe à notre échelle.

Dear Vibe coders. The obstacle to building a 9 figure SaaS/Software was never code. It was focusing on 1 thing and refining it for years. Which is why you have created 50 apps and a Open Claw that can do your taxes but have zero actual results.