Anglais

In clinics and research labs, the hardest part is often not clinical judgment itself. It is protecting the time and mental space that good judgment needs. Notes pile up, emails and forms multiply, analyses wait for a quiet hour that never comes, and decisions still need to be explained clearly on paper. That is the context where GPT‑5.5 becomes clinically interesting: not as a “flashier” model, but as a workflow shift. OpenAI describes it as quicker to grasp what you mean, better at multi‑step work, and more token‑efficient, which often means faster or cheaper iteration. In practice, “understanding what you’re trying to do” is the difference between an assistant that only rewrites sentences and one that helps protect clinical reasoning under time pressure. Think of a complex intake where trauma history, sleep disruption, substance use, and mood symptoms all compete for explanatory weight. A stronger model can help you keep the narrative coherent, track working hypotheses, and separate observed data from inference. The risk is that coherence can masquerade as truth, pulling us toward premature closure. Token efficiency sounds technical, but it changes behavior because it changes how often we revise. If rewriting a consent form, polishing a supervision email, simplifying discharge instructions, or translating psychoeducation becomes easier, teams will iterate more, which can improve clarity and reduce errors. The flip side is that low friction can invite “scope creep,” where the model gets used for higher‑stakes tasks. When language becomes easy to generate, uncertainty can get flattened into confident prose. A bigger shift companies point to is agentic work, meaning the tool does not only draft text but helps move tasks forward across steps and tools. In research, that can tighten the loop between analysis plans, code, and write‑up. In clinics, it can mean faster first drafts of letters, summaries, and resource guides, but these still require clinician review and sign‑off. The promise is less clerical drag, not replacement of clinical thinking. There is also a quieter team effect. If a tool holds context, tracks dependencies, and proposes next actions, people may offload planning and synthesis, which can help workloads but can also erode safety skills like noticing inconsistencies, challenging assumptions, and spotting what is missing. Better tools do not eliminate bias; they often redistribute it. Polished drafts can trigger automation bias (“it looks vetted”), and early formulations can become sticky through anchoring even when later evidence changes the picture. The practical safeguard is to keep clinical structure visible, even when drafting becomes effortless. It helps to consistently separate facts, interpretations, and decisions, and to repeatedly ask for alternatives: what else could explain this pattern, what would disconfirm it, and what uncertainty remains. In research, the most rigorous use is often method support rather than narrative generation, such as clearer preregistrations, audit trails for data cleaning, and standardized reporting. As capability grows, version control matters more: prompts, intermediate outputs, edits, and final decisions should be traceable for peer review or audit. Ethically, responsibility stays with the clinician or investigator, not the interface. Even if system documents describe safety work, they cannot replace local governance, privacy controls, and rules about what can be uploaded and who signs off on patient‑facing or decision‑relevant content. Transparency means being able to explain what the model touched, what it did not touch, and how outputs were checked. Bias monitoring must stay active, because fluent English can hide uneven errors across culture, disability, literacy, and socioeconomic context, especially in translated or simplified materials. A careful conclusion is restrained. The opportunity is not automated judgment, but better conditions for judgment. If token efficiency buys time and tool support reduces clerical burden, attention can return to formulation quality, alliance, measurement, and methodological rigor. The key question is not whether GPT‑5.5 “works,” but when it improves decisions, how it fails under stress, and what accountability structures keep human reasoning clearly in the driver’s seat.

In April 2026, AI companies released new tools very quickly, almost like running a marathon at sprint speed. This can feel confusing or overwhelming. But the main change is important: these tools are not only “chatbots” anymore. They are becoming work tools that can create things we use every day, handouts, summaries, visuals, forms, and drafts for decisions. The question “Which AI model is best?” usually comes up during real tasks. For example: writing a patient handout that is easy to understand, building a study web page, or testing a new intake form before funding deadlines. The danger is that AI can produce something that looks clean and confident, before we have checked if it is correct. So we need strong clinical habits: be clear about uncertainty, save versions, and double-check with trusted sources and real users. Here are the recent updates people are talking about. OpenAI released ChatGPT Images 2.0 on April 21, 2026, and also published a safety document explaining risks of realistic or misleading images. Anthropic released Claude Opus 4.7 and introduced Claude Design (a “canvas” tool for making visual assets) as a research preview on April 17, 2026. Google released Gemini 3.1 Pro (Preview) on February 19, 2026, and Gemini 3.1 Flash Lite (Preview) on March 3, 2026. Model comparison Model Company Context window Intelligence Index Price (USD / 1M tokens) Output speed (tokens/s) Latency (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 A key shift is that AI now creates “objects we think with.” That means not only text, but also prototypes, slide decks, intake screens, and structured case summaries. These outputs can help a team work faster and collaborate better. But they can also “freeze” early assumptions: if something is easy to generate, it may become easy to test, fund, and deploy, even if it is not the best option clinically. This is why cost and speed matter, not only “how smart” the model seems. Some models may be strong at reasoning but feel slow in real work because they take longer to start responding. In clinic-related workflows, if a tool feels slow, teams often stop using it, even if it is technically better. So what is the “best” model? A practical way to decide is to think about your main risk. If your biggest risk is conceptual or factual mistakes, you might accept higher cost or slower performance, and then add careful human review before anything reaches a client. If your biggest problem is volume (too many notes, forms, translations), a faster and cheaper model can be reasonable, if you use templates, rules, and review steps. The biggest ethical risk starts when AI creates something that looks “finished,” like a polished handout, a slide deck, or a clean user interface. When something looks professional, people trust it more, sometimes too quickly. That is why responsibility stays with humans: say when AI helped, keep track of prompts/versions/sources, and test materials with real users (clients, families, staff). If AI shapes care pathways, then accessibility, language, cultural fit, and data handling become clinical quality issues, not just tech details. The updates will keep coming. The safest stance is not “never use AI,” and not “trust it because it’s new.” It is: generate fast, but interpret slowly. Choose tools based on where errors could cause harm, and place checks exactly where harm would concentrate. If you want to follow updated numbers for price/speed/latency, the comparison source used here is Artificial Analysis’ leaderboard: https://artificialanalysis.ai/leaderboards/models

De nos jours, on dirait que l'IA apparaît partout. Un collègue mentionne un nouvel outil d'écriture de notes entre les sessions, un client cite quelque chose qu'un chatbot leur a dit, et une mise à jour de plateforme ajoute discrètement une fonctionnalité d'IA que vous n'avez jamais demandée. Au milieu d'un véritable travail clinique, il peut être difficile de savoir ce qui est vraiment utile, ce qui est hype, et ce qui soulève les drapeaux rouges éthiques. C'est pourquoi nous avons créé la communauté de formation du cerveau heureux. C'est un espace libre pour tous les thérapeutes qui veulent rester au courant de la dernière en Intelligence Artificielle et thérapie, sans le bruit et sans la pression pour devenir un expert en technologie du jour au lendemain. Nous l'avons construit comme nous voudrions un espace professionnel. Pratique, chaleureux et réaliste sur ce qui aide et ce qui ne le fait pas. Au sein de la communauté, nous partageons ce qui compte réellement pour la pratique quotidienne. De nouveaux outils d'IA et des mises à jour dans les soins de santé, ainsi que des innovations qui impactent la thérapie dans des environnements réels, pas seulement en théorie. Nous publions également des annonces de formations à venir, de sorte que vous n'avez pas à compter sur des messages dispersés ou des rappels de dernière minute. Il est 100% gratuit, conçu pour vous aider à rester informé, inspiré, et prêt pour l'avenir de la thérapie. Nous sommes aussi très intentionnels au sujet de l'éthique. Un outil utile n'est pas automatiquement un outil sûr, surtout lorsque la protection de la vie privée, le biais et la responsabilité clinique sont en jeu. Nous continuons à revenir à la même position clinique que beaucoup d'entre nous utilisent déjà dans d'autres domaines. Ralentissez, nommez clairement les risques et choisissez des mesures de protection qui protègent les clients et nos licences. Cette vision éthique est conforme aux grandes orientations en matière de responsabilité

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.

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.

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.

En thérapie, « données de santé » n'arrive presque jamais comme une histoire propre et la dernière mise à jour de la santé Perplexity s'appuie sur cette réalité. L'annonce se concentre sur de nouvelles intégrations qui permettent aux gens de rassembler des informations personnelles sur la santé, de les organiser en tableaux de bord et de les utiliser pour créer des résumés plus clairs et des questions pour les visites médicales. De la salle de thérapie, cela soulève immédiatement une question humaine: qu'est-ce qui change quand une personne peut recueillir ses signaux de santé en un seul endroit et parler à travers eux, au lieu de les poursuivre à travers des applications? D'un point de vue thérapeute, l'impact est simple et pratique : structure. Beaucoup de clients ont du mal à résumer ce qui se passe d'une manière qu'un clinicien peut utiliser, quand il a commencé, ce qui le déclenche, ce qui le rend meilleur ou pire, ce qui a été essayé, ce qui a changé, et comment il affecte le sommeil, le travail, l'appétit, l'humeur et les relations. Si un outil peut aider à rédiger un résumé avant la visite à partir du désordre de la vie réelle, qui peut réduire la charge cognitive, réduire la honte (« Je ne peux pas bien l'expliquer »), et aider quelqu'un à entrer dans un rendez-vous avec des questions plus claires et moins d'omissions. Mais les inconvénients et les défis sont réels, et ils ne sont pas seulement sur la configuration. Le plus grand que je vois cliniquement est qu'un seul tableau de bord peut tranquillement devenir un « moniteur de menace ». Pour les clients sujets à l'anxiété, à la panique, à la recherche d'une assurance de type OCD, au balayage du corps lié aux traumatismes ou au stress chronique, plus de suivi n'est pas toujours plus clair. Il peut augmenter le contrôle, amplifier les fluctuations normales, et garder le système nerveux en alerte, surtout lorsque les nombres se sentent comme v

A useful piece of information to keep in mind is this: many AI chatbots look “safe” in testing because they refuse obvious harmful requests, but they can still respond unsafely when the same intent is phrased indirectly. This is often described as keyword-based safety (catching flagged words) versus intent awareness (understanding what the person is actually trying to do). In other words, the model may pass safety checks by recognizing certain terms, yet fail when distress is expressed in more human, ambiguous language. What this means for our therapy practice is immediate: our clients rarely speak in clean, explicit “risk language.” They test the waters. They minimize. They speak in metaphors. They code-switch. They communicate through tone and omission. If a tool only “detects” risk when the client uses the right words, that tool mirrors the least helpful kind of assessment, one that rewards performance and misses lived experience. A second key reality: many models are trained to be warm, validating, and agreeable. That can feel supportive, but clinically we know validation without discernment can become reinforcement. As therapists, we validate emotion while gently challenging distortions, checking reality, and tracking function over time. An AI can unintentionally validate emotion, interpretation and impulsive plan all at once, because it’s optimized to be helpful and coherent, not to hold clinical responsibility. Then there’s AI bias, and in therapy we should assume it shows up in ways that matter. Models can respond differently based on dialect, second-language English, culture-shaped expressions of pain, or even how “organized” a story sounds. The client who is dysregulated, repetitive, or fragmented (often highest need) may get generic reassurance, while the client who is articulate and persuasive may get more detailed, confidence-sounding answers. That is not just unfair—it can skew risk, rapport, and decision-making. So practically, when a client tells us they’ve been using a chatbot, we don’t treat it as a quirky side detail anymore, we treat it like a new “third voice” in the system. We ask: When do you use it, before bed, after fights, during panic? What does it tend to say? Do you feel calmer, or more certain? Does it reduce shame, or does it keep you looping? That assessment gives us clinical data: the tool’s role (soothing, escalating, avoiding, rehearsing), and the client’s relationship with it (dependency, secrecy, relief, shame). In session, this information nudges us to be more explicit about the difference between emotional validation and clinical containment. We might say: “A chatbot can sound caring and still miss what we’re tracking, risk patterns, triggers, relapse signatures, coercion, dissociation, trauma responses.” This isn’t anti-tech; it’s psychoeducation. It helps clients understand why “it felt supportive” isn’t the same as “it was safe for my nervous system and my real-life consequences.” It also changes how we handle risk conversations. Because AI safety can be cue-based, we assume clients may have learned (without meaning to) that certain wording gets shut down and other wording gets rewarded. That can shape disclosure: clients may avoid direct language, or they may rehearse safer-sounding narratives. Practically, we make more room for graded disclosure: “If it’s hard to say plainly, can we circle it, what are the closest words you can tolerate right now?” That keeps the door open without forcing performance. On the provider side, it pushes us to tighten boundaries and documentation when AI touches our workflow. If we use AI for drafts (handouts, summaries, exercises), we treat it like an intern: we review every line, remove anything that sounds overconfident, and check for bias-laden assumptions (culture, gender roles, family expectations, “should” language). If an organization suggests AI note-writing, our clinical question becomes: where is the data going, who can access it, and what happens if the model invents details? Clinical responsibility doesn’t outsource. When we’re advising colleagues or a clinic, we translate all of this into simple evaluation questions: Does the tool stay safe over multiple turns, or does it drift into over-agreement? Does it respond appropriately to indirect distress? Does it treat different dialects and cultural expressions consistently? Does it have clear escalation behavior (crisis resources, “get human help”) without shaming? If a vendor can’t answer those plainly, we assume the tool is optimized for demos, not for therapy-adjacent reality. Finally, we treat AI bias as an equity issue inside care, not a tech footnote. We build it into supervision and training: we role-play indirect phrasing, different cultural idioms of distress, and coercive-relationship narratives to see how tools might misread them. And we tell clients something grounding: “Use it if it helps, but don’t let it become your judge, your diagnosis, or your safety plan.” In practice, that stance keeps us clinically responsible while acknowledging the world our clients already live in.

Le cadre politique national de la Maison-Blanche publié le 20 mars 2026 (qui date maintenant d'une semaine le 29 mars 2026) est mieux compris comme un projet de loi, et non comme un règlement terminé. Elle tente de fixer les termes du débat, ce que le Congrès devrait réglementer, ce qu'il devrait éviter et quels risques méritent la priorité. Pour les praticiens et les chercheurs, la vraie question est de savoir si ce plan se traduit par des protections opérationnelles ou reste au niveau de la messagerie. Au niveau des « expliquateurs », le document regroupe ses recommandations en sept domaines : la sécurité des enfants, les protections communautaires, le droit d'auteur, la liberté d'expression, l'innovation, la formation des travailleurs et la préemption fédérale. Cette structure est utile car elle montre ce que l'administration veut que le Congrès touche en premier. Mais il signale aussi un compromis : largeur sur profondeur, où chaque section peut pointer dans une direction sans préciser les normes, les seuils ou les muscles d'application. La revendication structurelle la plus profonde est la pression pour la préemption fédérale, l'idée que les règles d'IA devraient être principalement nationales, et non pas État par État. En théorie, une norme pourrait réduire le chaos de conformité et simplifier le déploiement interétatique. Dans la pratique, la préemption n'est pas neutre : elle décide si les garde-corps au niveau de l'État deviennent un terrain d'essai pour de meilleures protections ou s'ils sont effacés avant leur maturité. En ce qui concerne la sécurité des enfants et les protections communautaires, les instincts du cadre sont largement alignés sur ce que nous attendons d'une approche fondée sur le risque : prioriser les dommages les plus vulnérables et les plus évolutives. Pourtant, « protéger les enfants » peut devenir une bannière qui cache la question de conception dure

In research and clinical settings, Excel persists because it is fast, familiar, and flexible. Screening logs, adverse-event trackers, clinic volume summaries, and quality-improvement datasets often begin (and sometimes remain) as spreadsheets. What feels newly consequential is the possibility of working through language: describing what we want done and having an AI system build, update, analyze, or troubleshoot while leaving the spreadsheet’s layout and formulas largely intact. For teams already burdened by documentation and reporting cycles, that shift is not trivial. From the perspective of an experienced clinician-researcher, the appeal is less “automation” than the reduction of brittle, time-consuming micro-tasks. A surprising amount of spreadsheet labor involves extending a pattern across sheets, repairing references after columns change, harmonizing date and text formats, or generating consistent summaries under time pressure. Natural-language interaction can serve as a specification layer over formula work: “Add a flag for missed visits using our existing definition,” or “Extend this table to include the new site without changing the report format.” When it works, it allows attention to return to design decisions rather than keystrokes. The preservation of formatting, formulas, and structure matters more than it may sound. Many real-world spreadsheets encode institutional memory in their structure: color conventions, locked cells, named ranges, hidden calculation tabs, and formulas that implement local definitions. An AI assistant that edits aggressively, rebuilding tables, flattening formulas, or rearranging columns, can break downstream use even if the “answer” looks correct. The practical requirement, therefore, is not only correctness of outputs but respect for the spreadsheet as a system with dependencies. Building and updating are often the safest entry points. Adding new calculated columns, generating data-validation rules, or creating a summary sheet can be done in ways that are auditable and reversible, especially if the assistant is instructed to place changes in a new tab or clearly marked area. In clinical audit work, for instance, a natural-language request to create a monthly run chart or pivoted summary can save time, but it should also produce formulas that are visible and checkable. The goal is not to hide the work, but to make it quicker to draft and easier to review. Error diagnosis is where benefits and risks rise together. Spreadsheet errors are typically quiet: a mixed absolute/relative reference, a SUMIF range that fails to extend to the newest rows, a text-to-number conversion that quietly produces zeros, or a lookup that breaks when identifiers change format. An AI system can often propose plausible causes and minimal corrections, which is genuinely helpful when a deadline is near. Yet “minimal” is contextual; even a one-cell fix can alter denominators, eligibility flags, or baseline values in clinically meaningful ways. Analysis through natural language can also change who participates in interpretation. Not everyone in a multidisciplinary team reads nested formulas comfortably, and that gap can concentrate power in the hands of the person who “knows Excel.” If an assistant can translate a request, “Summarize no-show rates by site and month, and show how missing values were handled”, into transparent steps and clearly labeled outputs, the spreadsheet becomes more legible. That legibility has practical value: better peer review of calculations and fewer analytic choices hidden inside formulas. Still, there are tensions that cannot be solved by interface design alone. Natural language is ambiguous, while spreadsheets are literal; “clean the data” can mean anything from trimming spaces to redefining categories. AI-generated formulas may look convincing while being subtly wrong, and summaries can miss artifacts such as duplicated rows, shifted time windows, or changes in coding practice. For this reason, the most responsible use is procedural: versioning, before/after reconciliation totals, spot checks on known cases, and separation of raw data from transformed and reported outputs. Ethically, the central issues are transparency, privacy, and accountability rather than novelty. If patient-identifiable data are sent to an external tool without appropriate governance, no level of convenience justifies the breach of trust. Even in secure enterprise environments, teams should be explicit about where AI was used, what was changed, and who approved the final dataset or report. Data integrity is an ethical commitment: it requires an audit trail, a clear division of responsibility, and a refusal to treat AI output as self-validating. In practice, I have found it helpful to treat AI assistance as a junior collaborator: useful for drafting transformations, proposing checks, and explaining formula logic, but not a substitute for methodological judgment. Asking the system to show its work, formulas, assumptions, handling of missingness—and constraining it to preserve structure can reduce unintended disruption. The more consequential the spreadsheet (clinical decisions, regulatory reporting, publishable results), the more stringent the validation should be. Used this way, natural-language tools can support reliability rather than merely speed. Looking forward, the most meaningful shift may be cultural. Natural-language interaction encourages us to articulate definitions (“What counts as a missed visit?” “Which date anchors follow-up?”) before encoding them in formulas. If we pair that articulation with disciplined verification, we may end up with spreadsheets that are not only faster to maintain but also easier to audit, teach, and trust. In clinical research, that combination, clarity plus accountability, is the real promise.