Author name: Dr. Rania Kassir

French

GPT5.5 et l’évolution du travail clinique : temps, contrôle et responsabilité

Dans les cliniques et les laboratoires de recherche, la difficulté principale n’est souvent pas le jugement clinique lui-même, mais la préservation du temps et de l’espace mental nécessaires à ce jugement. Les notes s’accumulent, les emails et formulaires se multiplient, les analyses attendent un moment de calme qui n’arrive jamais, et les décisions doivent malgré tout être formalisées clairement. C’est dans ce contexte que GPT5.5 devient cliniquement pertinent : non pas comme un modèle plus spectaculaire, mais comme un levier de transformation des flux de travail. OpenAI le décrit comme plus rapide pour comprendre l’intention, plus performant sur des tâches complexes, et plus efficient en tokens, ce qui se traduit souvent par des itérations plus rapides ou moins coûteuses. En pratique, « comprendre ce que vous essayez de faire » distingue un assistant qui se contente de reformuler des phrases d’un outil qui aide à préserver le raisonnement clinique sous contrainte temporelle. Prenons l’exemple d’une évaluation complexe où antécédents traumatiques, troubles du sommeil, usage de substances et symptômes thymiques entrent en compétition explicative. Un modèle plus performant peut aider à maintenir une narration cohérente, suivre les hypothèses en cours et distinguer les données observées des inférences. Le risque est que la cohérence donne l’illusion de la vérité et favorise une fermeture prématurée du raisonnement. L’efficience en tokens peut sembler technique, mais elle influence les comportements en modifiant la fréquence des révisions. Si la réécriture d’un formulaire de consentement, l’amélioration d’un email de supervision, la simplification de consignes de sortie ou la traduction de psychoéducation deviennent plus faciles, les équipes itéreront davantage, ce qui peut améliorer la clarté et réduire les erreurs. À l’inverse, une friction réduite peut favoriser un élargissement des usages vers des tâches à plus fort enjeu. Lorsque le langage devient facile à produire, l’incertitude peut se transformer en discours assuré. Un changement plus profond concerne le travail agentif, c’est-à-dire la capacité de l’outil à faire avancer les tâches à travers plusieurs étapes et outils, et pas seulement à produire du texte. En recherche, cela peut resserrer la boucle entre plan d’analyse, code et rédaction. En clinique, cela peut accélérer la production de premières versions de lettres, synthèses et guides, qui nécessitent néanmoins validation et signature par un clinicien. La promesse est une réduction de la charge administrative, et non un remplacement du raisonnement clinique. Un effet plus discret concerne le travail en équipe. Si un outil conserve le contexte, suit les dépendances et propose des actions suivantes, les professionnels peuvent externaliser la planification et la synthèse, ce qui allège la charge mais peut aussi éroder des compétences de sécurité essentielles : détecter les incohérences, remettre en question les hypothèses et identifier les éléments manquants. Des outils plus performants n’éliminent pas les biais ; ils les redistribuent souvent. Des productions soignées peuvent induire un biais d’automatisation (« cela semble validé »), et des formulations initiales peuvent s’ancrer durablement même lorsque de nouvelles données apparaissent. La mesure de protection la plus concrète consiste à maintenir une structure clinique explicite, même lorsque la rédaction devient fluide. Il est utile de distinguer systématiquement faits, interprétations et décisions, et de solliciter régulièrement des alternatives : quelles autres hypothèses pourraient expliquer ce tableau, quels éléments permettraient de les invalider, et quelles incertitudes persistent. En recherche, l’usage le plus rigoureux concerne souvent le soutien méthodologique plutôt que la génération narrative, par exemple pour clarifier des pré-enregistrements, documenter les étapes de traitement des données et standardiser les rapports. À mesure que les capacités augmentent, le contrôle des versions devient central : prompts, productions intermédiaires, modifications et décisions finales doivent être traçables pour l’évaluation par les pairs ou l’audit. Sur le plan éthique, la responsabilité incombe toujours au clinicien ou au chercheur, et non à l’interface. Même si les documents systèmes décrivent des mesures de sécurité, ils ne remplacent pas la gouvernance locale, les contrôles de confidentialité et les règles encadrant les données pouvant être partagées, ainsi que les validations nécessaires pour les contenus destinés aux patients ou influençant les décisions. La transparence implique de pouvoir expliquer ce que le modèle a modifié, ce qu’il n’a pas modifié, et comment les productions ont été vérifiées. La surveillance des biais doit rester active, car une langue fluide peut masquer des erreurs inégales selon les contextes culturels, les handicaps, le niveau de littératie ou les conditions socio-économiques, en particulier dans les contenus traduits ou simplifiés. La conclusion doit rester mesurée. L’enjeu n’est pas l’automatisation du jugement, mais l’amélioration des conditions dans lesquelles il s’exerce. Si l’efficience en tokens libère du temps et que les outils réduisent la charge administrative, l’attention peut se recentrer sur la qualité de la formulation clinique, l’alliance thérapeutique, la mesure et la rigueur méthodologique. La question clé n’est pas de savoir si GPT5.5 « fonctionne », mais dans quelles conditions il améliore les décisions, comment il échoue sous contrainte, et quelles structures de responsabilité garantissent que le raisonnement humain reste clairement au centre.

French

La course insensée : le sprint des mises à jour en IA

En avril 2026, les entreprises d’IA ont publié de nouveaux outils à un rythme très rapide, presque comme si elles couraient un marathon à la vitesse d’un sprint. Cela peut sembler déroutant ou accablant. Pourtant, le changement principal est significatif : ces outils ne sont plus seulement des « chatbots ». Ils deviennent des outils de travail capables de produire des éléments que nous utilisons au quotidien : documents, synthèses, visuels, formulaires et ébauches de décisions. La question « Quel est le meilleur modèle d’IA ? » apparaît généralement dans des tâches concrètes. Par exemple : rédiger une fiche patient compréhensible, construire une page web d’étude ou tester un nouveau formulaire d’admission avant des échéances de financement. Le risque est que l’IA produise des contenus propres et assurés avant que leur exactitude n’ait été vérifiée. Il est donc essentiel de maintenir des habitudes cliniques solides : expliciter l’incertitude, conserver les versions, et vérifier systématiquement à l’aide de sources fiables et d’utilisateurs réels. Voici les mises à jour récentes les plus commentées. OpenAI a lancé ChatGPT Images 2.0 le 21 avril 2026, ainsi qu’un document de sécurité détaillant les risques liés aux images réalistes ou trompeuses. Anthropic a publié Claude Opus 4.7 et introduit Claude Design (un outil de type « canvas » pour la création d’actifs visuels) en version de recherche le 17 avril 2026. Google a lancé Gemini 3.1 Pro (Preview) le 19 février 2026, puis Gemini 3.1 Flash Lite (Preview) le 3 mars 2026. Comparaison des modèles Modèle Entreprise Fenêtre de contexte Indice d’intelligence Prix (USD / 1M tokens) Vitesse de sortie (tokens/s) Latence (TTFT, s) GPT-5.5 (xhigh) OpenAI 922k 60 11.25 74 63.19 GPT-5.5 (high) OpenAI 922k 59 11.25 78 28.01 Claude Opus 4.7 (max) Anthropic 1M 57 10.00 48 17.57 Gemini 3.1 Pro (Preview) Google 1M 57 4.50 116 21.53 Gemini 3.1 Flash Lite (Prev) Google 1M 34 0.56 313 5.08 Un changement majeur est que l’IA crée désormais des « objets avec lesquels penser ». Cela inclut non seulement du texte, mais aussi des prototypes, des présentations, des interfaces d’admission et des synthèses structurées de cas. Ces productions peuvent accélérer le travail en équipe et améliorer la collaboration. Mais elles peuvent aussi figer des hypothèses précoces : si quelque chose est facile à générer, cela devient facile à tester, financer et déployer, même si ce n’est pas la meilleure option sur le plan clinique. C’est pourquoi le coût et la vitesse comptent, et pas seulement le niveau d’intelligence perçu. Certains modèles peuvent être performants en raisonnement mais sembler lents en pratique car ils mettent plus de temps à démarrer. Dans les flux de travail cliniques, un outil perçu comme lent est souvent abandonné, même s’il est techniquement supérieur. Alors, quel est le « meilleur » modèle ? Une approche pragmatique consiste à identifier le principal risque. Si le risque majeur concerne des erreurs conceptuelles ou factuelles, il peut être pertinent d’accepter un coût plus élevé ou une vitesse moindre, en ajoutant une relecture humaine rigoureuse avant toute utilisation auprès d’un patient. Si le principal enjeu est le volume (notes, formulaires, traductions), un modèle plus rapide et moins coûteux peut être adapté, à condition d’intégrer des gabarits, des règles et des étapes de vérification. Le principal risque éthique apparaît lorsque l’IA produit quelque chose qui semble « finalisé » : une fiche soignée, une présentation structurée ou une interface claire. Lorsqu’un contenu paraît professionnel, il inspire davantage confiance, parfois trop rapidement. C’est pourquoi la responsabilité reste humaine : indiquer l’usage de l’IA, conserver une traçabilité des prompts, des versions et des sources, et tester les supports avec des utilisateurs réels (patients, familles, équipes). Si l’IA influence les parcours de soins, alors l’accessibilité, la langue, l’adéquation culturelle et la gestion des données deviennent des enjeux de qualité clinique, et non de simples aspects techniques. Les mises à jour vont se poursuivre. La posture la plus sûre n’est ni de refuser l’IA, ni de lui faire confiance parce qu’elle est nouvelle. Elle consiste à générer rapidement, mais interpréter lentement. Choisir les outils en fonction des zones où les erreurs peuvent causer des dommages, et placer les contrôles précisément là où ces dommages sont les plus susceptibles de survenir. Si vous souhaitez suivre les évolutions des indicateurs de prix, vitesse et latence, la source de comparaison utilisée ici est le classement d’Artificial Analysis : https://artificialanalysis.ai/leaderboards/models

French

Happy Brain Training Community : rester informé, éthique et inspiré à l’ère de l’IA

Aujourd’hui, l’IA semble apparaître partout à la fois. Un collègue évoque un nouvel outil de rédaction de notes entre deux séances, un patient cite une réponse donnée par un chatbot, et une plateforme ajoute discrètement une fonctionnalité d’IA que vous n’aviez pas demandée. Au cœur du travail clinique réel, il devient difficile de distinguer ce qui est véritablement utile, ce qui relève de l’effet de mode et ce qui soulève des enjeux éthiques. C’est pour cette raison que nous avons créé la Happy Brain Training Community. Il s’agit d’un espace gratuit destiné à tous les thérapeutes qui souhaitent rester informés des avancées en intelligence artificielle et en thérapie, sans surcharge informationnelle ni pression à devenir experts techniques du jour au lendemain. Nous l’avons conçu comme nous souhaiterions qu’un espace professionnel soit : pratique, chaleureux et réaliste quant à ce qui aide réellement. Au sein de la communauté, nous partageons ce qui compte pour la pratique quotidienne. De nouveaux outils d’IA, des mises à jour en santé et des innovations qui ont un impact concret en thérapie, et pas seulement en théorie. Nous publions également des annonces de formations à venir, afin d’éviter de dépendre de publications dispersées ou de rappels de dernière minute. L’ensemble est entièrement gratuit, pensé pour vous aider à rester informé, inspiré et prêt pour l’avenir de la thérapie. Nous accordons également une attention particulière aux enjeux éthiques. Un outil utile n’est pas automatiquement un outil sûr, notamment lorsqu’il est question de confidentialité, de biais et de responsabilité clinique. Nous revenons à une posture clinique familière : ralentir, nommer clairement les risques et choisir des garde-fous qui protègent à la fois les patients et notre responsabilité professionnelle. Cette approche est cohérente avec les recommandations majeures en matière d’IA responsable en santé et de gestion des risques. Concrètement, cette communauté vise à réduire la fatigue décisionnelle. Plutôt que de réinventer chacun de notre côté, nous pouvons comparer les pratiques en matière de planification de séances, de psychoéducation et d’organisation du travail thérapeutique, tout en restant clairs sur ce qui ne doit jamais être automatisé. Elle offre également un espace pour aborder des questions concrètes : comment répondre à un patient qui s’appuie sur des conseils générés par une IA, ou comment poser des limites lorsqu’un outil semble utile mais éthiquement incertain. Un point important : pour des raisons internationales, la langue de la communauté est l’anglais, afin de permettre des échanges entre thérapeutes de différents pays et systèmes. Notre intention est simple : rester informé, rester éthique, rester inspiré. Si cela vous parle, nous serons ravis de vous accueillir. Lien : https://chat.whatsapp.com/ELZIqaf4eY6C7MoROCPrG7

French

« JITRO » de Google et la logique clinique d’une IA orientée par objectifs : quand les systèmes cessent d’attendre des prompts

Lors des réunions de recherche clinique, une tension récurrente devient difficile à ignorer : nous souhaitons une automatisation qui réduise les erreurs et libère de l’attention pour le jugement, tout en redoutant de perdre en visibilité sur la manière dont les décisions sont produites. C’est dans ce contexte que circulent des publications et commentaires en ligne sur « JITRO » de Google. L’idée centrale n’est pas une simple évolution des copilotes existants, mais l’émergence d’une catégorie différente d’IA, qui n’attend plus d’instructions ponctuelles parce qu’elle est structurée autour d’objectifs plutôt que d’échanges conversationnels. Dans ces descriptions, JITRO est présenté comme un agent de codage autonome développé par Google, constituant une étape de nouvelle génération au-delà de Jules. L’interaction proposée s’apparente davantage à une délégation : vous définissez un résultat, et le système détermine le chemin, les étapes intermédiaires et le plan d’exécution. Autrement dit, il s’agit d’un passage d’une IA outil à une IA auto-pilotée, où le rôle humain évolue d’opérateur à superviseur plutôt que rédacteur principal. Il est utile d’ancrer cela dans les éléments officiellement documentés. Jules est présenté comme un agent de codage asynchrone capable de travailler sur un dépôt dans un environnement cloud dédié, de proposer un plan, d’implémenter des modifications, puis de dépendre d’une validation humaine avant intégration. Ce choix de conception n’est pas anecdotique : il incarne un principe de sécurité déjà familier en formation Clinique, l’autonomie peut être utile, mais elle doit rester encadrée par des productions vérifiables et une validation responsable. Pour les cliniciens et les chercheurs en santé, un « agent de codage autonome » devient pertinent dès lors que l’on reconnaît que notre base de connaissances est médiée par des logiciels. Les essais et évaluations de services reposent sur des scripts de prétraitement, du code de cotation, des tableaux de bord d’événements indésirables et des analyses versionnées susceptibles de dériver sans être détectées. Un système capable d’identifier les modifications nécessaires dans un code pour améliorer la couverture de tests ou réduire les erreurs peut renforcer la fiabilité, mais il déplace également le risque vers l’infrastructure qui rend nos méthodes opérantes. La différence avec les outils basés sur des prompts ne tient pas seulement à la vitesse, mais à une redistribution de la décomposition des tâches. Dans un flux de travail guidé par prompts, l’humain découpe les étapes et oriente en continu. Dans un flux orienté par objectifs, le système effectue lui-même cette décomposition, et vous évaluez ensuite le plan, les modifications et les preuves que l’objectif est atteint. Cliniquement, cela s’apparente à la différence entre guider un stagiaire minute par minute et superviser un plan de prise en charge autonome. La recherche sur les facteurs humains aide à comprendre pourquoi cette transition peut sembler trompeusement « facile ». À mesure que les systèmes passent de l’assistance à l’action, le rôle humain devient celui de la surveillance, une activité cognitivement exigeante et vulnérable à la surconfiance sous pression temporelle. Dans l’aide à la décision clinique, le biais d’automatisation correspond à une diminution de la détection d’erreurs en présence de suggestions automatisées, en particulier lorsque les flux de travail valorisent la rapidité. Un agent d’ingénierie persistant peut créer une vulnérabilité analogue : plus il paraît compétent, moins nous interrogeons les cas limites. C’est pourquoi l’accent mis sur les points de validation n’est pas un simple détail technique. L’enjeu pratique est de savoir si ces points offrent une véritable inspectabilité, plans clairs, preuves de test, correspondance intelligible entre objectifs et modifications de code, plutôt qu’un simple feu vert final. Sans justifications lisibles et validation significative, le « human-in-the-loop » risque de devenir performatif, en particulier dans des bases de code volumineuses où personne ne peut tout examiner de manière exhaustive. Plusieurs incertitudes doivent être explicitement reconnues. Le terme « JITRO » apparaît davantage dans des commentaires informels que dans une documentation technique primaire, ce qui implique de considérer ses capacités comme provisoires. Néanmoins, en tant que concept, il cristallise une transition en cours : ne plus considérer l’IA comme quelque chose que l’on sollicite par prompts, mais comme un système à qui l’on donne une direction. Ce changement de perspective peut rendre les outils existants plus puissants, tout en transformant la définition des objectifs en un acte méthodologique à part entière. Sur le plan éthique, les agents orientés par objectifs accentuent des obligations déjà bien établies en contexte clinique et de recherche. La responsabilité demeure du côté de l’équipe humaine, même lorsque le système est l’auteur proximal des modifications ; la transparence doit être conçue de manière à rendre les décisions reconstructibles ; et l’intégrité des données repose sur des dispositifs de gouvernance, de test et d’audit capables de détecter les dérives. Les cadres de gestion du risque insistent sur la responsabilité et le suivi continu, et ces exigences deviennent plus importantes, et non moins, à mesure que l’autonomie augmente. L’attitude la plus constructive n’est ni le rejet ni l’enthousiasme naïf, mais une curiosité disciplinée : si les agents orientés par objectifs deviennent des coéquipiers en ingénierie, nous devons développer une science de la supervision à la hauteur. Cela implique d’étudier quels dispositifs de validation réduisent réellement les erreurs, comment quantifier la dérive dans des pipelines modifiés par des agents, et comment préserver l’interprétabilité lorsque les plans sont générés par des systèmes optimisés pour le débit. La transition est peut-être en cours, mais sa valeur clinique dépendra de notre capacité à concilier automatisation orientée vers les résultats, rigueur méthodologique et responsabilité.

English

Happy Brain Training Community: Staying Informed, Ethical, and Inspired in the Age of AI

These days, it feels like AI is showing up everywhere at once. A colleague mentions a new note writing tool between sessions, a client quotes something a chatbot told them, and a platform update quietly adds an AI feature you never asked for. In the middle of real clinical work, it can be hard to know what is genuinely useful, what is hype, and what raises ethical red flags. That is why we created the Happy Brain Training Community. It is a free space for all therapists who want to stay updated on the latest in Artificial Intelligence and therapy, without the noise and without the pressure to become a tech expert overnight. We built it the way we would want a professional space to feel. Practical, warm, and realistic about what helps and what does not. Inside the community, we share what actually matters for day to day practice. New AI tools and updates in healthcare, plus innovations that impact therapy in real settings, not just in theory. We also post announcements of upcoming trainings, so you do not have to rely on scattered posts or last minute reminders. It is 100% free, designed to help you stay informed, inspired, and ready for the future of therapy. We are also very intentional about ethics. A helpful tool is not automatically a safe tool, especially when privacy, bias, and clinical responsibility are involved. We keep coming back to the same clinical stance many of us already use in other areas. Slow down, name the risks clearly, and choose safeguards that protect clients and protect our licenses. That ethical lens is consistent with major guidance on responsible AI in health contexts and risk management. Practically, this community is meant to reduce decision fatigue. Instead of each of us reinventing the wheel, we can compare notes on what is working for session planning, psychoeducation, and therapist workflows, while staying clear about what should never be automated. We also make space for the real clinician questions, like how to talk with clients who bring AI generated advice into sessions, or how to set boundaries when a tool feels helpful but ethically fuzzy. One important note. For international reasons, the language of the community is English, so therapists across different countries and systems can actually learn together in one shared space. Our hope is simple and steady: Stay informed. Stay ethical. Stay inspired. If that resonates, we would love to have you with us. Link : https://chat.whatsapp.com/ELZIqaf4eY6C7MoROCPrG7

English

Google’s “JITRO” and the Clinical Logic of Goal-Driven AI: When Systems Stop Waiting to Be Prompted

In clinical research meetings, a recurring tension is becoming hard to ignore: we want automation that reduces error and frees attention for judgment, yet we worry about losing visibility into how decisions are produced. That is the backdrop against which online reporting and commentary about Google’s “JITRO” has been circulating. The core claim is not that this is an update to existing copilots, but a different category of AI, one that does not wait for your prompt because it is organized around goals rather than turns in a chat. In these descriptions, JITRO is framed as an autonomous coding agent built by Google as a next-generation step beyond Jules. The proposed interaction is closer to delegation: you define an outcome, and the system determines the path, intermediate steps, and execution plan. Put simply, it marks a shift from AI as a tool to AI as a self-driving system, with the human role moving from operator to supervisor rather than typist-in-chief. It helps to anchor this in what is officially documented. Google’s Jules is presented as an asynchronous coding agent that can work with a repository in a dedicated cloud environment, propose a plan, implement changes, and then depend on human review before merging. That design choice is not cosmetic; it encodes a safety principle we already rely on in clinical training: autonomy can be useful, but it must be bounded by reviewable work products and accountable sign-off. For clinicians and health researchers, an “autonomous coding agent” becomes relevant as soon as we acknowledge that our evidence base is software-mediated. Trials and service evaluations depend on preprocessing scripts, scoring code, dashboards for adverse events, and versioned analyses that can drift without anyone noticing. A system that can identify what needs to change in a codebase to raise test coverage or lower error rates might strengthen reliability, but it also relocates risk into the infrastructure that operationalizes our methods. The difference from prompt-based tools is not merely speed; it is a change in who performs task decomposition. In a prompt-based workflow, the human breaks the work into steps and continuously steers. In a goal-driven workflow, the system decomposes the work on its own, and you assess the plan, the edits, and the evidence that the goal has been met. Clinically, this resembles the difference between instructing a trainee minute-by-minute and supervising their independent management plan. Human factors research helps explain why this transition can feel deceptively “easy.” As systems move from assisting to acting, the human role often becomes monitoring, an activity that is cognitively demanding and vulnerable to over-trust under time pressure. In clinical decision support, automation bias describes reduced error detection when automated suggestions are present, especially when workflows reward speed. A persistent engineering agent can create an analogous vulnerability: the more competent it appears, the less likely we are to interrogate edge cases. This is why the reported emphasis on approval checkpoints is not a minor implementation detail. The practical issue is whether checkpoints deliver real inspectability, clear plans, test evidence, and an intelligible mapping from goal to code edits, rather than a single yes/no gate at the end. Without legible rationales and meaningful validation, “human-in-the-loop” can become performative, particularly in large codebases where no one can realistically scrutinize everything. Several uncertainties should be stated plainly. “JITRO” itself appears more in informal commentary than in primary technical documentation, so its exact capabilities should be treated as provisional. Still, as a concept it crystallizes a live transition: stop thinking of AI as something you prompt, and start thinking of it as something you give direction to. That reframing can make existing tools more powerful, and also makes goal specification a methodological act, not a convenience. Ethically, goal-driven agents sharpen familiar obligations in clinical and research settings. Responsibility remains with the human team even when the system is the proximate “author” of code changes; transparency must be engineered so decisions are reconstructible; and data integrity depends on governance, testing, and audit trails that detect drift. Risk frameworks emphasize accountability and ongoing monitoring, and those expectations become more, not less, important as autonomy increases. The most constructive stance is neither dismissal nor enthusiasm, but disciplined curiosity: if goal-driven agents are becoming engineering teammates, we need supervision science to match. That includes studying which checkpoint designs actually reduce error, how to quantify drift in agent-modified pipelines, and how to preserve interpretability when plans are generated by systems optimized for throughput. The shift may be underway, but its clinical value will depend on whether outcome-driven automation can be made compatible with methodological rigor and accountable care.

English

A New Cyber Risk in the Therapy Room: Why Project Glasswing Changes the Trust Equation

Cybersecurity isn’t a niche IT problem anymore. It’s a condition of modern life: banking, education, government services, and healthcare all run on fragile layers of software we rarely see. Most people only notice this fragility when something goes wrong—an outage, a breach, a locked account, a system that suddenly can’t be trusted. The risk is broad, but the consequences aren’t evenly distributed. In healthcare, that unevenness is felt fast. When digital systems fail, care doesn’t politely pause until things come back online. People still show up distressed, unsafe, or mid-crisis, and clinicians still have to hold decisions with incomplete information. The “technical incident” becomes a human one, often within minutes. That’s why therapists should care even when the conversation sounds far away from our day-to-day work. In therapy, cybersecurity rarely announces itself as “cyber.” It shows up as a session abruptly canceled because scheduling is down, a telehealth link that fails at the last moment, or a clinic suddenly unable to access notes. It also shows up as a client asking, quietly but directly, whether their messages are truly private. Against that background, Anthropic’s April 7, 2026 announcement of Project Glasswing is more than tech news. They described an unreleased model, Claude Mythos Preview, and emphasized that it will not be made generally available. Instead, it’s being routed through a restricted program, framed around defensive use. When an AI lab decides a model is too capable to release, that’s a signal about where the threat landscape is heading. The key reason given for the lockdown is simple and unsettling: Anthropic presents Mythos Preview as able to find serious vulnerabilities with very little human steering. In plain terms, it can reportedly spot weak points in software faster and more autonomously than earlier systems. Even if the intention is defense, the capability itself matters, because capabilities tend to spread, and because attackers also adapt. Anthropic’s examples are the kind that make non-technical people uneasy for good reason. They highlight weaknesses in widely used foundational software and describe cases where issues persisted for years, even decades, without being caught. That’s the uncomfortable truth about digital infrastructure: many systems we treat as stable are stitched together from codebases with long histories, uneven maintenance, and hidden complexity. If that still feels abstract, bring it back to the tools we actually use. Telehealth platforms rely on browsers, operating systems, servers, and third-party libraries. Scheduling systems and patient portals depend on integrations and APIs that can quietly multiply risk. A vulnerability “somewhere upstream” can become downtime, data exposure, or service disruption right where clients meet care. There’s also a structural question that matters for healthcare: who gets access to the strongest protective tools, and when? Restricting a high-capability model may reduce immediate misuse, but it also concentrates power and expertise in a small set of organizations. Smaller clinics and vendors can end up dependent on security timelines, priorities, and disclosure decisions they can’t easily see or influence. That gap, between ethical expectations and technical realities—can become a trust problem. Practically, this pushes us toward a more explicit, system-level view of clinical risk. We can’t patch operating systems, but we can treat cybersecurity maturity as part of quality of care. That means asking better procurement questions, requiring clear incident response commitments from vendors, and maintaining downtime protocols that protect continuity. It also means reducing “shadow tools” and unmanaged AI add-ons that expand the attack surface without oversight. Ethically, the goal isn’t to panic, it’s to insist on defensible trust. In clinical contexts, “trustworthy” should mean there are decision trails we can explain: what system was used, what data moved, what safeguards existed, what logging and auditing were in place, and how errors or incidents will be corrected and disclosed. Clients shouldn’t have to rely on invisible infrastructure and hope for the best; they deserve care systems built to fail safely. Project Glasswing is a preview of a new phase: AI is not only changing clinical tools, but also changing the security environment those tools sit inside. Patient trust depends on confidentiality, integrity, and availability, and those depend on infrastructure now being stress-tested by increasingly autonomous systems. For therapists, the task is to keep the clinical frame intact as the technical frame accelerates: protect continuity, protect privacy, and advocate for systems we can actually stand behind.

English

When the Model Stays on Your Device: Gemma 4, “Free Forever,” and What Privacy Really Means

In clinic, the friction point is rarely curiosity about AI; it’s governance. A supervisee wants help rewriting a sensitive school report, summarizing an OT evaluation, or drafting a consent form in simpler Arabic, then asks the question we all recognize: “Can I paste the real text?” The ethical discomfort is that most chat systems are cloud-mediated by design, and our default answer becomes a risk-management lecture rather than a clinically useful pathway. That’s why the claim, “Imagine ChatGPT, but installed directly on your device… private, offline, and free,” spreads so quickly. It sounds like the long-promised reconciliation of capability and confidentiality. But slogans are not safeguards, and “CEO energy” is not a clinical governance framework. Even when a tool comes from a major company, brand is not a substitute for evaluating workflows, auditability, and failure modes. What this points to, more precisely, is the growing ecosystem of local-capable models, including Gemma 4, that can be downloaded and run in environments you control. The practical promise is simple: you ask questions, it drafts text, it helps structure documentation, and in some setups it can support image-related work, while computation can happen on your own device. That “where the model runs” detail is not cosmetic; it is the whole privacy story. The “price” point matters for therapists because it changes adoption pressure and boundaries. If a model is “free” to download and run, the barrier shifts from subscription gatekeeping to hardware limits and setup time. You still “pay,” just differently: battery/heat, local storage, occasional troubleshooting, and the need for someone to own maintenance. But the psychological shift is important, capability feels close enough to use in real workflows, not only as a toy. Here is where the comparison belongs, because it sits right inside that workflow decision: you are choosing not only an AI, but a data path. Gemma 4 is one local option, but not the only one; many people also run DeepSeek-style models locally, and others choose Llama, Mistral, or Qwen depending on hardware and licensing comfort. The short comparison is this: local models (Gemma/DeepSeek/Llama/Mistral/Qwen run on-device) can support stricter confidentiality by keeping text in-house, while cloud models (ChatGPT/Claude/Gemini-style) often deliver stronger convenience and scalability but require clearer rules because identifiable data may leave your device unless you have an enterprise-controlled setup. That’s why the phrase “Google sees nothing” is directionally true only under a specific condition: you are actually running it locally. “Local” is not a vibe; it’s an implementation choice—offline runtime, no hidden uploads, and settings you can verify. If you test the model in a browser demo, a hosted notebook, or any web app, you’re no longer in “offline” territory, and you should treat it like any other cloud tool: fine for synthetic or de-identified material, not fine for identifiable documents unless policy explicitly allows it. Clinically, the most defensible value proposition of local inference is not novelty; it is a narrower but meaningful shift in what can be done without exporting identifiable data. Drafting discharge summaries in a consistent format, creating parent-friendly psychoeducation, adapting worksheets across reading levels, or generating structured session-plan templates can reduce administrative load. If the model is truly running offline, these tasks can be done while keeping protected content on the device, closer to the practical spirit of confidentiality, even when policy language lags behind technology. Evidence-based practice pushes a harder question: where does this help clinical reasoning rather than merely accelerate text production? The risk is that fluent output can masquerade as warranted inference, especially in formulations, risk narratives, or “professional-sounding” reports that feel authoritative because they read well. Used well, a local model supports the plumbing of care (formatting, translation drafts, checklists, reflective prompts), while the clinician retains responsibility for interpretation, differential thinking, and the therapeutic relationship. The “no limits” claim also deserves a clinician’s skepticism. Local models are not capped by a subscription counter, but they are constrained by memory, thermals, battery, and model size trade-offs. More importantly, offline does not equal harmless: hallucinations, bias, and overconfidence persist, and sometimes become more insidious when the system feels safe because it is private. Ethically, local AI concentrates accountability rather than dissolving it. If a clinician chooses to process identifiable material on-device, they also inherit responsibilities around device security, app telemetry/logging, model provenance, update hygiene, and documentation of use. Transparency is a workflow discipline: noting when AI assistance was used, what kind of inputs were provided, and how outputs were verified supports data integrity and defensible decision-making. What is most clinically interesting here is not the bravado of “offline intelligence,” but the opening of a more nuanced design space. Small local models for privacy-sensitive drafting; larger systems for literature work under controlled governance; and hybrid approaches that treat AI as an assistant to clinical judgment rather than a proxy for it. The next wave of useful work, worthy of supervision projects and pragmatic trials, is testing whether local inference measurably reduces documentation burden and improves patient comprehension without quietly eroding standards of verification.

French

Un nouveau risque cyber dans la salle de thérapie : pourquoi Project Glasswing change l’équation de la confiance

La cybersécurité n’est plus un problème technique de niche. C’est une condition de la vie moderne : banque, éducation, services publics et santé reposent sur des couches fragiles de logiciels que nous voyons rarement. La plupart des gens ne remarquent cette fragilité que lorsque quelque chose déraille : une panne, une violation, un compte bloqué, un système soudainement indigne de confiance. Le risque est large, mais les conséquences ne sont pas également réparties. En santé, cette inégalité se fait sentir rapidement. Lorsque les systèmes numériques défaillent, les soins ne se mettent pas poliment en pause le temps du rétablissement. Les personnes se présentent toujours en détresse, en insécurité ou en pleine crise, et les cliniciens doivent continuer de décider avec des informations incomplètes. L’« incident technique » devient humain, souvent en quelques minutes. C’est pourquoi les thérapeutes doivent s’y intéresser, même si la conversation semble éloignée du quotidien clinique. En thérapie, la cybersécurité ne s’annonce que rarement comme telle. Elle se manifeste par une séance annulée inopinément parce que la planification est en panne, un lien de téléconsultation qui échoue à la dernière minute, ou une clinique soudain incapable d’accéder aux notes. Elle se manifeste aussi lorsqu’un client demande, calmement mais directement, si ses messages sont réellement privés. Dans ce contexte, l’annonce d’Anthropic du 7 avril 2026 sur Project Glasswing est plus qu’une actualité technologique. L’entreprise y décrit un modèle non publié, Claude Mythos Preview, et insiste sur le fait qu’il ne sera pas rendu disponible au grand public. Il est plutôt acheminé via un programme restreint, présenté comme à usage défensif. Lorsqu’un laboratoire d’IA décide qu’un modèle est trop capable pour être diffusé, c’est un signal sur l’orientation du paysage des menaces. La raison clé avancée pour ce verrouillage est simple et troublante : Anthropic présente Mythos Preview comme étant capable de trouver des vulnérabilités graves avec très peu de pilotage humain. En termes clairs, il repérerait des points faibles logiciels plus vite et de façon plus autonome que les systèmes antérieurs. Même si l’intention est défensive, la capacité en elle‑même importe, car les capacités tendent à se diffuser et les attaquants s’adaptent. Les exemples d’Anthropic sont de ceux qui mettent mal à l’aise, à juste titre, les non‑techniciens. Ils mettent en lumière des faiblesses dans des logiciels fondamentaux très utilisés et décrivent des cas où des problèmes ont persisté des années, voire des décennies, sans être détectés. Voilà la vérité inconfortable de l’infrastructure numérique : beaucoup de systèmes que nous pensons stables sont assemblés à partir de bases de code anciennes, à maintenance inégale et à la complexité cachée. Si cela paraît encore abstrait, ramenons‑le aux outils que nous utilisons effectivement. Les plateformes de téléconsultation reposent sur des navigateurs, des systèmes d’exploitation, des serveurs et des bibliothèques tierces. Les systèmes d’agenda et les portails patients dépendent d’intégrations et d’API qui peuvent multiplier silencieusement les risques. Une vulnérabilité « quelque part en amont » peut se traduire par une indisponibilité, une exposition de données ou une interruption de service au point de contact entre le client et le soin. Il existe aussi une question structurelle importante pour la santé : qui accède aux moyens de protection les plus puissants, et quand ? Restreindre un modèle très performant peut réduire les mésusages immédiats, mais concentre aussi le pouvoir et l’expertise entre quelques organisations. Les petites cliniques et éditeurs se retrouvent dépendants de calendriers de sécurité, de priorités et de décisions de divulgation qu’ils ne voient ni n’influencent aisément. Cet écart, entre attentes éthiques et réalités techniques, peut devenir un problème de confiance. Concrètement, cela nous pousse vers une vision plus explicite et systémique du risque clinique. Nous ne pouvons pas corriger des systèmes d’exploitation, mais nous pouvons intégrer la maturité cybersécurité à la qualité des soins. Cela signifie poser de meilleures questions à l’achat, exiger des engagements clairs de réponse aux incidents de la part des fournisseurs, et maintenir des protocoles de continuité en mode dégradé. Cela signifie aussi réduire les « outils fantômes » et les modules IA non gérés qui élargissent la surface d’attaque sans supervision. Éthiquement, l’enjeu n’est pas d’alimenter la panique, mais d’exiger une confiance défendable. En contexte clinique, « digne de confiance » devrait signifier qu’il existe des traces décisionnelles explicables : quel système a été utilisé, quelles données ont circulé, quelles protections étaient en place, quelle journalisation et quel audit existaient, et comment les erreurs ou incidents seront corrigés et divulgués. Les clients ne devraient pas avoir à s’en remettre à une infrastructure invisible et « espérer le meilleur » ; ils méritent des systèmes de soin conçus pour échouer sans nuire. Project Glasswing préfigure une nouvelle phase : l’IA ne transforme pas seulement les outils cliniques, elle modifie aussi l’environnement de sécurité dans lequel ces outils s’inscrivent. La confiance des patients dépend de la confidentialité, de l’intégrité et de la disponibilité, des propriétés qui reposent sur une infrastructure désormais mise à l’épreuve par des systèmes de plus en plus autonomes. Pour les thérapeutes, la tâche est de préserver le cadre clinique à mesure que le cadre technique s’accélère : protéger la continuité, protéger la vie privée et plaider pour des systèmes que nous pouvons réellement assumer.

French

Quand le modèle reste sur votre appareil : Gemma 4, « gratuit pour toujours » et ce que la confidentialité signifie réellement

En clinique, le point de friction n’est presque jamais la curiosité pour l’IA ; c’est la gouvernance. Un supervisé souhaite de l’aide pour réécrire un rapport scolaire sensible, résumer une évaluation en ergothérapie ou rédiger un formulaire de consentement en arabe simplifié, puis pose la question que nous connaissons tous : « Puis-je coller le texte réel ? » L’inconfort éthique tient au fait que la plupart des systèmes conversationnels sont, par conception, médiés par le cloud, et notre réponse devient alors un cours de gestion des risques plutôt qu’un appui cliniquement utile. C’est pourquoi l’affirmation « Imaginez ChatGPT, mais installé directement sur votre appareil… privé, hors ligne et gratuit » se diffuse si rapidement. Elle évoque la réconciliation promise entre capacité et confidentialité. Mais les slogans ne sont pas des garde-fous, et « l’énergie de PDG » ne constitue pas un cadre de gouvernance clinique. Même lorsqu’un outil provient d’une grande entreprise, la marque ne remplace pas l’évaluation des flux de travail, de l’auditabilité et des modes de défaillance. Ce que cela traduit plus précisément, c’est l’essor d’un écosystème de modèles « local capable », dont Gemma 4, téléchargeables et exécutables dans des environnements contrôlés. La promesse est simple : poser des questions, générer du texte, structurer la documentation et, dans certaines configurations, traiter aussi des tâches liées à l’image, avec un calcul effectué sur votre propre appareil. Ce détail — l’endroit où s’exécute le modèle — n’est pas anecdotique : il est au cœur de la confidentialité. La question du « prix » est déterminante pour les thérapeutes, car elle modifie les dynamiques d’adoption. Si un modèle est « gratuit » à télécharger et à exécuter, la contrainte se déplace vers les exigences matérielles et le temps de configuration. Vous « payez » autrement : batterie, chauffe, stockage, maintenance et dépannage. Mais le changement psychologique est majeur : la technologie devient suffisamment accessible pour s’intégrer dans des pratiques réelles, et non plus seulement comme un outil expérimental. La comparaison est donc pertinente, car elle touche au cœur du flux de travail : vous choisissez une IA, mais aussi un circuit de données. Gemma 4 est une option locale, mais pas la seule. De nombreux utilisateurs exécutent également des modèles de type DeepSeek, tandis que d’autres optent pour Llama, Mistral ou Qwen selon leur matériel et leurs contraintes de licence. En résumé : les modèles locaux peuvent soutenir une confidentialité plus stricte en gardant les données en interne, tandis que les modèles cloud (ChatGPT, Claude, Gemini) offrent davantage de commodité et d’évolutivité, mais exigent des règles plus rigoureuses. La formule « Google ne voit rien » n’est donc vraie que sous une condition précise : une exécution réellement locale. Le « local » n’est pas une perception, mais une implémentation : exécution hors ligne, absence de téléversements, paramètres vérifiables. Toute utilisation via navigateur ou application web doit être considérée comme du cloud. Cliniquement, l’intérêt majeur de l’IA locale n’est pas la nouveauté, mais l’élargissement des tâches réalisables sans exposition de données sensibles : rédaction de courriers, psychoéducation, adaptation de supports, création de canevas de séance. Cela réduit la charge administrative tout en respectant davantage l’esprit de la confidentialité. Cependant, une question essentielle demeure : cela améliore-t-il réellement le raisonnement clinique ? Le risque est qu’une production fluide donne l’illusion d’une validité clinique. L’IA doit rester un outil de structuration et non un substitut au jugement clinique. L’idée de « sans limites » doit également être nuancée. Les modèles locaux ne sont pas limités par un abonnement, mais restent contraints par le matériel. Et surtout, « hors ligne » ne signifie pas « fiable » : biais et hallucinations persistent. Sur le plan éthique, l’IA locale concentre la responsabilité. Utiliser des données identifiables implique de maîtriser la sécurité de l’appareil, la journalisation, la provenance du modèle et la traçabilité de l’usage. La transparence devient une pratique : documenter quand et comment l’IA est utilisée. Ce qui est cliniquement intéressant, ce n’est pas l’illusion d’une « IA privée parfaite », mais la possibilité de concevoir des usages hybrides et nuancés : modèles locaux pour les contenus sensibles, systèmes cloud pour les tâches documentaires sous gouvernance.

Shopping Cart