La séparation claire entre Services et Administration rend immédiatement la finalité de la plateforme compréhensible et met en évidence sa valeur pour les habitant·e·s et les entreprises. L’intention du site est ainsi immédiatement perceptible, avec des contenus structurés de manière logique et cohérente. Ce n’est pas seulement notre avis: le jury des BOSW l’a également reconnu en attribuant cette année un bronze dans la catégorie User Experience (un peu de fausse modestie: nous avons occupé deux des trois places du podium, avec également l’argent pour le nouveau site du Museum für Gestaltung Zürich).

Une architecture de l’information pensée utilisateur·rice·s

L’architecture de l’information est soigneusement conçue et adaptée aux besoins des publics cibles. Tous les services sont centralisés, clairement catégorisés et suivent une structure cohérente pour répondre aux questions: de quoi ai-je besoin, comment se déroule le processus et quels sont les canaux disponibles?

Cette standardisation permet de comprendre rapidement les infos pertinentes et de naviguer avec assurance dans des processus complexes. Les informations sur les services sont aussi présentées de manière transparente, afin que même les utilisateur·rice·s occasionnel·le·s puissent immédiatement identifier les étapes à suivre.

Fonctionnalité, interactivité et utilisabilité au service de l’efficacité

Les fonctionnalités du site sont conçues en fonction des besoins des utilisateur·rice·s. Chaque page de service propose des instructions claires et faciles à comprendre, ainsi que des éléments intuitifs et simples à utiliser. Le tout avec un accompagnement à chaque étape: que ce soit via des services numériques ou des canaux plus traditionnels comme des formulaires, des appels téléphoniques ou des visites sur place.

Cette approche réduit les incertitudes, limite les demandes de clarification et améliore l’efficacité dans l’accès aux services cantonaux.

Un site inclusif conçu pour tou·te·s

so.ch respecte les normes d’accessibilité numérique conformément aux directives WAI, garantissant un accès équitable à tou·te·s les utilisateur·rice·s. Les contenus sont rédigés de manière claire, la navigation est cohérente, les interactions sont intuitives, et la plateforme prend en charge des accès numériques et non numériques.

Ainsi, chacun·e peut utiliser le site de manière efficace et autonome, indépendamment de son expérience technique, de son âge ou de ses capacités.

En se concentrant systématiquement sur les besoins des utilisateur·rice·s, so.ch propose une plateforme intuitive, transparente et inclusive qui rend les processus administratifs complexes compréhensibles. Des objectifs clairs, une architecture de l’information réfléchie, des fonctionnalités accessibles et un design sans barrières créent une expérience centrée sur l’utilisateur·rice. Ce qui permet de simplifier et optimiser les interactions avec les services cantonaux.

Souhaitez-vous améliorer le site web de votre organisation? Je serais ravi d’en savoir plus sur vos besoins et vos défis.

Au fin 2022, j'ai vu ChatGPT pour la première fois dans une vidéo TikTok et je l'ai tout de suite essayé. Il pouvait m'expliquer des contenus plus rapidement que mes enseignant·e·s, résoudre des tâches mieux que si je les avais faites moi-même, et même développer des idées auxquelles je n'aurais jamais pensé. Ça m'a vraiment fasciné.

Mais c'est seulement en commençant mon apprentissage que j'ai réalisé à quel point l'IA est puissante et importante. Aujourd'hui, je l'utilise quotidiennement. Pas pour qu'elle fasse mon travail à ma place, mais pour apprendre de nouvelles choses, faire des recherches plus efficacement et travailler plus efficacement sur certaines tâches.

Mon apprentissage est varié. C'est justement ce qui le rend passionnant

J'effectue un apprentissage de Développeur·euse en Commerce Numérique CFC. J'en suis actuellement à ma deuxième année. Après la première année au Bbc Basislehrjahr, j'ai rejoint Liip durant l'été 2025.

Ce que je trouve particulièrement passionnant dans cet apprentissage, c'est la diversité des tâches. Je travaille dans différents Circles, des équipes auto-organisées basées sur l'holacratie. Cela me permet de découvrir de nombreuses perspectives, tâches et personnes différentes.

Cette variété me correspond bien. J'aime travailler de façon structurée, je communique activement et je trouve stimulant d'analyser et d'améliorer les processus de travail. Chez Liip, j'ai la chance de pouvoir prendre des responsabilités tôt dans mon apprentissage. Je travaille sur des projets internes et externes concrets, je prends des décisions et j'apporte mes propres idées. Pour moi, c'est ce qui distingue vraiment Liip de nombreux autres employeurs proposant des apprentissages.

La relation avec les clients en fait partie

Un aspect de mon apprentissage peut-être moins visible de l'extérieur réside dans la relation avec les clients. J'apprends à communiquer de façon professionnelle, à bien représenter mon entreprise et à comprendre les facteurs importants pour une bonne collaboration. Cela implique notamment de transmettre des informations claires au sein de l'équipe, de recueillir des exigences et de communiquer de manière structurée dans les projets. Parce que je participe à de vrais projets dès le début de mon apprentissage, je développe rapidement un bon sens de ce qui compte réellement pour les clients.

Comment j'utilise l'IA concrètement

L'IA devient particulièrement utile quand je lui fournis beaucoup de contexte. Un outil généraliste se transforme alors en véritable partenaire de réflexion. L'IA me soutient surtout quand j'ai un objectif clair et que j'ai besoin d'une bonne première ébauche rapidement. Je l'utilise pour brainstormer, comprendre de nouveaux termes, faire des recherches ou structurer des textes.

• Anecdote au passage: ce billet de blog a aussi été partiellement structuré avec l'IA. J'ai rassemblé mes idées, expliqué le contexte, puis j'ai reçu de l'aide pour créer une structure cohérente. C'est comme ça que j'utilise l'IA au quotidien.

Un bon exemple est le manuel pour le backend LiipGPT que j'ai rédigé. Au départ, je n'avais pratiquement aucune expérience dans la rédaction de manuels. J'ai donc d'abord appris les bases avec l'aide de l'IA. Ensuite, j'ai fourni un maximum de contexte à l'IA et développé une ébauche étape par étape avec elle. Le résultat est un manuel utilisé régulièrement en interne et adapté individuellement pour les clients. Pour moi, c'est le moment où j'ai réalisé la valeur ajoutée que l'IA peut apporter: je pouvais non seulement travailler plus vite et sans expérience préalable, mais aussi créer un résultat qui aide vraiment les autres dans leur quotidien.

Je n'utilise pas ces outils sans réfléchir. Je les teste, je les compare et je réfléchis soigneusement aux cas d'usage où ils ont pleinement du sens.

L'IA, mon meilleur compagnon d'apprentissage

L'IA a un fort potentiel pour l'apprentissage. Elle simplifie les contenus, donne des exemples et s'adapte à mon niveau. Aucun manuel ne peut faire ça. Prendre en main un nouveau sujet devient ainsi plus rapide. En tant qu'apprenti·e, je pose à l'IA des questions et des questions de suivi que je n'oserais pas poser en classe.

En même temps: l'IA ne doit jamais remplacer ta propre réflexion. Ceux et celles qui ne comprennent pas comment l'IA fonctionne et comment l'utiliser finiront par très peu apprendre.

Pour moi, l'ouverture d'esprit et le questionnement critique font partie intégrante de l'utilisation de nouveaux outils. L'IA peut autonomiser les apprenant·e·s, mais uniquement si elle est utilisée consciemment comme un outil. C'est pourquoi il est important que les apprenti·e·s se familiarisent avec l'IA pendant leur formation. Pas plus tard, quand tout le monde sera déjà utilisateur·rice chevronné·e.

Et toi, comment utilises-tu l'IA?

Peut-être vaut-il la peine de faire une courte pause après ce billet de blog et de réfléchir à ta propre utilisation de l'IA. Comment utilises-tu vraiment l'IA dans ton quotidien aujourd'hui? Quelle valeur ajoutée concrète t'apporte-t-elle? Est-ce simplement un outil que tu essaies de temps en temps? Ou est-ce que tu l'utilises consciemment pour travailler mieux, plus vite ou de façon plus structurée?

Chez Liip, je vis directement comment une organisation n'utilise pas seulement l'IA, mais la façonne activement:

• des échanges de connaissances réguliers et des Liip Talks sur l'IA, des nouveaux modèles aux questions éthiques.
• des formations à l'IA pour tou·te·s les collaborateur·rice·s. En interne, nous proposons des ateliers et des modules spéciaux pour que chacun·e reste à l'aise avec l'utilisation de l'IA.
• le développement et la mise à jour de nos propres outils IA comme LiipGPT, déjà utilisé par des clients des secteurs de la santé, du droit et du secteur public.
• des lignes directrices sur l'IA durable, un cadre interne qui garantit que les projets d'IA sont mis en oeuvre de façon éthique et durable.

Cela me montre à quoi peut ressembler une organisation qui ne déploie pas l'IA aveuglément, mais qui en assume la responsabilité.

Comment les collaborateur·rice·s de ton entreprise utilisent-ils·elles l'IA? Y a-t-il des règles claires ou des offres pour utiliser l'IA de façon pertinente? Où l'IA pourrait-elle concrètement te soutenir dans ton rôle si tu l'utilisais de manière plus délibérée?

L'IA n'est pas un concept figé qui fonctionne de la même manière pour tout le monde. Mais ceux et celles qui l'utilisent tôt réalisent rapidement: la question n'est pas de savoir si tu as encore besoin d'un apprentissage, mais combien tu en tires davantage grâce à l'IA.

Museum für Gestaltung: un chef-d’œuvre d’intérêt public et d’expérience utilisateur

Le nouveau site du Museum für Gestaltung Zürich sert de hub central pour la communication digitale du musée et permet aux visiteur·euse·s de créer un lien avec celui-ci. En co-création, nous avons conçu une solution qui laisse le design s’exprimer pleinement, au service d’une plus grande valeur publique. Le jury des BOSW l’a reconnu en attribuant au site le prix d’argent dans les catégories “User Experience” et “Public Value”.

En savoir plus sur le projet primé

Comme le souligne Clelia Kanai, Head of Marketing & Communication:
«Pour nous, le design signifie clarté et responsabilité – y compris dans le domaine numérique. Avec Liip, nous avons trouvé un partenaire qui partage et porte ces valeurs, de la conception initiale jusqu’à la vérification finale de l’accessibilité. Le fait que ce projet ait été récompensé par deux prix d’argent aux BOSW, dans les catégories User Experience et Public Value, est à la fois une validation et une magnifique reconnaissance pour nous.»

so.ch: transparence, accessibilité et simplicité pour renforcer la confiance du public

Nous avons développé un nouveau site pour le canton de Soleure, so.ch. Il crée une véritable valeur publique en rendant les services cantonaux transparents, accessibles et faciles à comprendre, renforçant ainsi la confiance du public, des autorités locales et des acteur·rice·s économiques dans les services publics.

Comme bs.ch nous l’a montré l’an dernier, un site centré utilisateur·rice est essentiel pour améliorer le quotidien des citoyen·ne·s, qui doivent de plus en plus accéder à leurs informations et documents en ligne. Le jury a reconnu la qualité de l’expérience utilisateur de so.ch en attribuant le bronze dans cette catégorie clé.

En savoir plus sur le projet primé

Même si nous n’avons pas remporté autant de prix que nous l’aurions souhaité (et que nous pensons bien sûr mériter :), c’était une belle occasion de prendre le pouls du secteur. Nous félicitons chaleureusement « Swissgrid 24/7 », Master of Swiss Web 26. À l’année prochaine!

À la lumière des récents développements politiques, un « do-talk gap » a (une fois de plus) été constaté dans le domaine de la durabilité. La Zurich Climate Week s’attaque précisément à ce point: s’engager face à l’urgence climatique et en parler.

Et c’est exactement ce dont nous avons besoin aujourd’hui. Car la transformation durable ne se fait pas en silence. Elle naît là où des perspectives différentes se rencontrent: économie, politique, recherche et société civile. Là où les connaissances sont partagées. Là où des solutions sont développées et mises à l’échelle ensemble.

Pourquoi nous nous engageons

Chez Liip, nous avons décidé de contribuer au programme de la Zurich Climate Week pour plusieurs raisons:

• Pour soutenir l’initiative en participant activement au programme
• Pour renforcer notre engagement en faveur de la durabilité au-delà de la Climate Week
• Et surtout: pour partager nos expériences, apprendre des autres et élargir notre réseau de personnes engagées

Notre contribution à la Climate Week, tout comme les deux thématiques de nos événements, s’inscrit selon un même principe: assumer notre responsabilité.

Notre contribution

Liip est présent dans le programme avec deux formats, tous deux axés sur l’échange, la pratique et la mise en œuvre concrète.

Hacking for Sustainable AI

Plus d’informations & inscription

L’intelligence artificielle fait désormais partie de notre quotidien. Elle semble offrir des solutions à de nombreux problèmes et constitue souvent le premier réflexe lorsque nous arrivons à une impasse. Pourtant, ses impacts environnementaux et sociétaux restent encore largement sous-estimés.

Dans quels cas l’IA crée-t-elle réellement de la valeur? Et comment l’utiliser de manière à contribuer à un avenir plus durable?

En collaboration avec opendata.ch, nous mettons ces questions au centre d’un mini hackathon. Développeur·euse·s, designer·euse·s, expert·e·s en durabilité, entreprises et toute personne intéressée sont invité·e·s à imaginer ensemble de nouvelles idées, prototypes et perspectives.

👉 Objectif: développer des approches concrètes pour utiliser l’IA de manière pertinente, responsable et à fort impact.

Sustainability Reporting for SMEs: Real Cases, Practical Steps

Plus d’informations & inscription

Les PME jouent un rôle central dans la transformation durable. Et pourtant, beaucoup se posent les mêmes questions: par où commencer? Qu’est-ce qui est vraiment pertinent? Et quel est le niveau d’effort nécessaire?

Dans cette session, 4 PME partagent leur expérience du reporting de durabilité volontaire.

Le format est interactif: sous forme de table ronde, les participant·e·s peuvent poser des questions, partager leurs propres approches et discuter ensemble des moyens de surmonter les obstacles.

👉 Objectif: réduire les difficultés de départ, montrer que le premier pas est accessible et faire grandir une communauté de PME engagées.

Du discours à l’action collective

La Zurich Climate Week incarne un état d’esprit que nous partageons: allier urgence et optimisme. Ne pas seulement parler des problèmes, mais faire avancer des solutions concrètes. Assumer ensemble notre responsabilité et générer un impact réel.

Dans un contexte où les incertitudes augmentent et où les priorités évoluent, il est plus important que jamais de rester engagés. La durabilité n’est pas une tendance à court terme mais bien une nécessité à long terme. Et en même temps, une opportunité: pour l’innovation, pour de nouveaux modèles économiques, pour une différenciation réelle et au final pour une meilleure qualité de vie.

Ce dont nous avons besoin, ce sont davantage d’espaces d’échange. Plus de transparence. Et plus de courage pour partager ce qui est encore en construction.

La Zurich Climate Week crée précisément ces espaces. Nous sommes ravis d’en faire partie.

The application does one - rather complicated - task, with lots of business logic. There was no way we could rewrite it to include it directly into the website code. And because the application comes with its own Javascript and CSS, we decided to use an iframe to embed the application with clean isolation.

The company maintaining that application provided us with a version - running as a Docker container - where they had stripped all extra elements like the navigation, so that it would visually fit within the website. There was however no way for us to customise anything within the application.

iframe security

The promise of an iframe is to keep a clean security boundary between embedding page and embedded content. This means that it is by design not possible to call Javascript across the boundary.

Because injecting iframes could potentially trick a user into submitting data to an attacker (clickjacking), as the iframe may be from a different origin than the main page. Thus, to even render the iframe, the browser checks the Content-Security-Policy (CSP) HTTP header. That header has a field frame-src to control what may be included as an iframe. With this, I allowed the domain of the application to be included in iframes.

Content-Security-Policy: frame-src https://my-embed.com;

But not only does the including page need to allow an iframe. The page to be embedded also needs to allow being included with the frame-ancestors attribute of the CSP header. As we run the application Docker image under our control, I was able to add that header in the proxy that runs before the Docker image:

Content-Security-Policy: frame-ancestors https://my-website.com;

Several things to note:

• If you have other CSP rules, merge them with the rules, nginx will overwrite the header and not add to it
• Both options also support "self" to allow embedding resp. being embedded with the same webserver
• Prior to the CSP becoming a standard, there was an unofficial header X-Frame-Options, which is still supported by browsers
• Content-Security-Policy must be an actual HTTP header, <meta http-equiv=”...”> is ignored for Content-Security-Policy (and also ignored for X-Frame-Options).

Size of the iframe element

Now we get to the weird parts. To prevent multiple scrollbars, we need the iframe element to be exactly big enough for the embedded page. If it is too small, there is an additional scrollbar (or hidden content). If it is too large, there is odd whitespace.

The size of the element needs to be set on the iframe, owned by the parent. The dimensions of the content are however only known by the embedded application. HTML / CSS do not provide any means to let the parent page declare that it wants the iframe to have the “necessary size”.

We ended up with a really convoluted way, which seems the only way to achieve this: sending messages from the child page to the parent. This problem spawned dedicated javascript libraries like iframe-resizer. We ended up reimplementing the logic in the React application, as it was so small that a dedicated library felt like overkill. Following the tutorial at iframe-height (which also has some interesting background on the discussion about iframes in the Whatwg), we came up with this code for the containing website:

// register an event listener for messages
window.addEventListener('message', receiveMessage, false);

// handle a message
function receiveMessage(event) {
    const origin = event.origin || event.originalEvent.origin;
    // we configure the expected domain to allow for this additional sanity check
    if (expectedDomain !== origin) {
      return;
    }
    if (!event.data.request || 'iframeResize' !== event.data.request) {
      return;
    }
    // the id is known in the js class. we need to find the element that needs to be resized
    const iframe = document.getElementById(`iframe-${id}`);
    if (iframe) {
      // pad the height a bit to avoid unnecessary tiny scrolling
      iframe.style.height = (event.data.height + 20) + 'px';
      // width could be handled the same way if necessary - in our case the width is fix
    }
}

Now we need to make the embedded content send a message with its height. The Javascript for that is a bit verbose to allow for different browsers, but not complicated either:

(
    function(document, window) {
      if (undefined === parent || !document.addEventListener) {
        return;
      }
      function init() {
        let owner = null;
        const width = Math.max(document.body.scrollWidth, document.body.offsetWidth, document.documentElement.clientWidth, document.documentElement.scrollWidth, document.documentElement.offsetWidth);
        const height = Math.max(document.body.scrollHeight, document.body.offsetHeight, document.documentElement.clientHeight, document.documentElement.scrollHeight, document.documentElement.offsetHeight);
        if (parent.postMessage) {
          owner = parent;
        } else if (parent.contentWindow && parent.contentWindow.postMessage) {
          owner = parent.contentWindow;
        } else {
          return;
        }
        owner.postMessage({
          'request' : 'iframeResize',
          'width' : width,
          'height' : height
        }, '*');
      }

      if (document.readyState !== 'loading') {
        window.setTimeout(init);
      } else {
        document.addEventListener('DOMContentLoaded', init);
      }
      // this is needed to also adjust the iframe if something (e.g. the Javascript of the application) changes the size of the iframe without an actual page reload.
      const observer = new ResizeObserver(init);
      observer.observe(document.body);
    }
  )(document, window);"

iframes with same origin

If the iframe comes from the same origin (= domain) as the parent page, Javascript can cross the boundary. From parent to child, there is a contentWindow property on the iframe element. From child to parent, there is window.parent. With same origin, those elements expose all things the window usually has. For different origins, they only expose the function postMessage for the secure separation.

Injecting content with Nginx

Remember how I said we can’t modify the application? That still holds true. If we would have loaded both applications from the same domain, we could have had the parent page add a listener inside the iframe to directly update dimensions as needed. But the application contained absolute paths for its assets, so providing it from a subfolder of the same domain would have been tricky and we had to run it on a separate domain.

I ended up injecting the above snippet of Javascript in the Nginx proxy that sits in front of the Docker container:

proxy_set_header Accept-Encoding ""; # make sure we get plain response for substitution to work
...
sub_filter_last_modified on;
sub_filter "</body>" "<script language='javascript'>${script}</script></body>";
sub_filter_once on;
...
proxy_pass https://my-embed.com$request_uri;

Now the embedded iframe communicates its size to the containing page, which adjusts the iframe size accordingly.

(Note that Nginx does not execute these statements in order. The sub_filter instructions apply to the response, wihle proxy_set_header and proxy_pass apply to the request.)

Alternatives

Web Components are a more lightweight solution to combine separate sources into one website. If what you need to integrate is just an element and not a whole application, they might be a better fit. My collegue Falk wrote about Web Components last week.

Bonus: Access control for the iframe content

Because the application is not under our control, we need to manage access to it. We told the supplier of the application to remove access control and simply allow items to be created and edited by ID. Of course, this means that the application must never be directly exposed to the internet, but only reachable through the proxy.

On the embedding side, we track which user is allowed what ids, and have Nginx do a pre-flight check against the website to get the access decision:

# at the beginning of the location for the main request to the embeded application
auth_request /auth;

location /auth {
    # preflight authorization request with symfony
    fastcgi_pass phpfcgi;
    include /usr/local/openresty/nginx/conf/fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /app/public/index.php;
    # forward the original request URI to allow our main application to verify access to the specific resource
    fastcgi_param REQUEST_URI /embed-check$request_uri;
    # body is not forwarded. we have to remove content length separately, otherwise PHP-FPM will wait for the body until the auth request times out.
    fastcgi_pass_request_body off;
    fastcgi_param CONTENT_LENGTH "";
    fastcgi_param CONTENT_TYPE "";
    internal;
}

If the call at /embed-check/... returns a 2xx status, Nginx continues with the request, otherwise it returns the response with the status code to the client, allowing for example to redirect to the login page. In my case, i return an empty response with status 204 if the user is allowed to access the specific resource.

On Symfony side, I use Symfony security to make sure the user is logged in. And then parse the path to know which item in the application the request wants to access, and check if the user has access. This leaks knowledge about the URL design of the embedded application, which is not avoidable for granular access control.

Here are practical techniques to prevent it.

Session Hygiene

Start a fresh session for each task. This is the simplest technique and the easiest to get right. If earlier research is needed, write it into a temporary handoff file and let a new session pick up from there.

Streamline Tool Calling

Every tool call adds tokens to the context. Poorly built tools add a lot of them. To keep the context lean:

• Choose tools and MCPs that are well built and optimize token usage
• Make sure via prompting that the right tools are used from the start

A single bloated tool response can waste more context than an entire conversation turn.

Subagents

Agents can spawn other agents that run in their own context. This isolates work and keeps the parent context clean. It helps most when building large features where individual parts are independent.

The easiest way to use subagents is to prompt something like:

Split the current plan into tasks, use a subagent for each task.

Persistent Tasks

I built an MCP for Claude Code called deliverables-mcp that lets an agent create persistent tasks per codebase. Tasks are stored in .claude/deliverables.jsonl and persist across sessions.

This allows:

• Starting a new session before implementing each task
• Running subagents in parallel based on tasks dependencies
• Restarting a failed task in a clean session

The tool replaces Claude Code's internal tasks and is deliberately called "deliverables" for two reasons:

1. To avoid confusing the agent with two tools both called "tasks"
2. Deliverables are typically larger than just a task, which is a sweet spot for AI agents. Not so small that handoff cost dominates, but small enough that context problems are rare.

You can check out deliverables-mcp on GitHub.

Un article publié par les initiateurs et initiatrices de ce projet dans le dernier numéro de la Revue Médicale Suisse dresse un bilan provisoire, un an après la mise en ligne publique.

Un chatbot officiel plutôt que des réponses parfois erronées sur le net

La médecine de premier recours, essentielle au bon fonctionnement du système de santé, fait face à une pénurie croissante, même en ville. Faute d’accès à leur médecin traitant, les patients sont incités à rechercher des réponses sur internet, qui sont souvent erronées voire dangereuses.

Dans ce contexte, une solution IA bien pensée pourrait apporter la bonne information au bon moment.

C’est pourquoi nous avons accompagné les HUG à développer un chatbot de type RAG (Retrieval Augmented Generation). ConfIAnce n’est pas le premier chatbot destiné aux patients. Cependant, il se distingue par “son ancrage institutionnel, l’utilisation de contenus médicaux validés localement, et la mise en place de couches de contrôle pour garantir la fiabilité des réponses”.

Pour garantir la sécurité, il intègre des systèmes de contrôle rigoureux: matching, groundedness, harmfulness, tests automatiques, routage sémantique.

Garder le contrôle de l’outil pour assurer la qualité

L’un des enjeux est de bien garder le contrôle de l’outil, ce qui nécessite des fonctionnalités de surveillance du chatbot. Pour ce faire, des tests automatisés sont effectués sur l’ensemble des réponses apportées aux questions posées. On y mesure la cohérence factuelle de la réponse générée par le chatbot par rapport au contenu de la base de connaissances (faithfullness).

De plus, un routage, ajustable par les administrateurs, garantit un contrôle humain en filtrant et en dirigeant les questions de manière appropriée. Les administrateurs peuvent aussi mettre le chatbot immédiatement hors ligne en cas de suspicion de dysfonctionnement.
Les thèmes peu abordés dans les documents sources et qui sont pourtant un sujet de questions vont aussi être développés pour enrichir la base de connaissances dans un processus d’amélioration continue.

Un tel outil, aussi performant soit-il, n’est utile que s’il est adopté

Pour que le chatbot soit utilisé par les patients, les HUG ont mené une campagne d’information publique. L’objectif était de promouvoir l’outil, tout en restant réaliste quant aux attentes des patient·e·s.

Ce n’est pas un dispositif médical qui se substitue à une visite, mais bien un soutien informationnel permettant de répondre à des questions portant sur les maladies chroniques les plus courantes chez les adultes.

En février 2025, ConfIAnce sort en version beta. Entre début février et fin octobre 2025, 3'823 utilisateurs ont interagi avec le chatbot, donnant lieu à 5'969 conversations et 11'781 questions (soit environ deux questions par conversation).

Les feedbacks donnés directement au chatbot sont à 75% positifs.

Une bonne acceptabilité de ce chatbot différent des autres

Si les chatbots dans le parcours de santé sont bien acceptés par les patients par leur disponibilité continue et leur facilité d’usage, des études montrent que les problèmes décelés concernent l’hétérogénéité de la qualité des réponses données et l’opacité des sources utilisées.

Ce sont là des éléments qui permettent de distinguer ConfIAnce d’autres chatbots médicaux.

Destiné à encourager, et non à remplacer, les relations directes entre les patients et les médecins, ConfIAnce “permet de soutenir les médecins de premier recours en leur libérant du temps de qualité pour pratiquer avec humanité le métier qu’ils ont choisi d’exercer.”

Les auteur·rices de l’article de la Revue Médicale Suisse soulignent à quel point ce chatbot développé dans le contexte spécifique des HUG et de leurs bases d’information peut être transposé dans d’autres contextes institutionnels. Pour que la réussite soit au rendez-vous, il nous semble nécessaire de bénéficier d'abord de données de qualité comme c’était le cas ici. Mais ce n’est pas tout, les couches de contrôle, les tests automatiques et les feedbacks utilisateurs permettent ensuite une amélioration continue pour garantir la sécurité et la pertinence nécessaires à la confiance.

Notre parcours vers l’accessibilité s’est articulé autour de quatre étapes principales: des scans automatiques et quick fixes, la navigation au clavier, l’optimisation pour le zoom mobile ainsi que l’optimisation pour les lecteur·rice·s d’écran.

Scans automatiques et quick fixes

Nous avons commencé par des tests automatisés d’accessibilité à l’aide d’extensions de navigateur comme IBM Equal Access Accessibility Checker et axe DevTools. Ces outils nous ont aidé·e·s à identifier des problèmes fréquents: labels manquants, contraste de couleurs insuffisant, HTML sémantique incorrect et attributs ARIA absents. Bien que les scans automatisés ne détectent qu’environ 40 % des problèmes d’accessibilité, ils constituent une base de départ solide.

Navigation au clavier

Une navigation correcte au clavier est fondamentale pour l’accessibilité. Garantir que la navigation de base avec la touche Tab fonctionne dans toute l’application est relativement simple. Des composants plus complexes comme les tabs, les menus et les fenêtres de dialogue nécessitent cependant des interactions clavier plus avancées comme l'utilisation des flèches directionnelles, la gestion de la touche Escape ou encore la gestion du focus selon les directives officielles du W3C. Les utilisateur·rice·s qui dépendent de la navigation au clavier s’attendent à ces schémas spécifiques. S’en écarter provoque confusion et frustration. Plutôt que d’implémenter ces schémas depuis zéro, nous avons utilisé Bits UI, une bibliothèque headless UI qui applique correctement ces directives d’accessibilité.

Au-delà des composants individuels, nous avons également implémenté des boucles de focus et une restauration du focus au niveau de l’application afin que les utilisateur·rice·s restent toujours orienté·e·s en passant d’une zone de l’interface du chat à une autre.

Optimisation pour le zoom mobile

Lors de tests utilisateur pour meinplatz.ch avec des personnes en situation de handicap, nous avons observé quelque chose de frappant: beaucoup naviguent sur les sites web sur mobile avec un zoom de 200 % ou plus et tiennent leur appareil à environ 10 cm de leurs yeux. Cette observation a mis en évidence une lacune critique dans la plupart des implémentations de chatbots.

La majorité des chatbots utilisent des éléments à position fixe: un champ de saisie en bas de l’écran et souvent un en-tête en haut. Lorsque les utilisateur·rice·s zooment fortement, ces éléments fixes peuvent occuper tout le viewport et rendre l’interface inutilisable. Malheureusement, les navigateurs ne permettent pas de détecter de manière fiable le niveau de zoom. Pour résoudre cela, nous utilisons l’Intersection Observer pour détecter lorsque l’en-tête ou le pied de page occupe plus d’espace que prévu. Dans ce cas, nous supprimons dynamiquement leur position fixe afin de rétablir l’utilisabilité.

Expérience avec les lecteurs d’écran

L’accessibilité pour les lecteur·rice·s d’écran n’apparaît pas automatiquement, elle nécessite une conception attentive. Nous nous sommes concentré·e·s sur la fourniture d’un contexte clair grâce à une structure de page propre (landmarks et titres). Les utilisateur·rice·s comprennent ainsi toujours où iels se trouvent et ce qui se passe, tout en disposant de raccourcis vers les zones les plus importantes de l’application.

Fournir du contexte

Nous avons implémenté une structure d’outline complète avec des landmarks pour la navigation principale, les paramètres et les zones de saisie. Chaque message contient des titres et des labels corrects. De plus, nous avons ajouté après le champ de saisie du chat (en bas de page) un skip-link permettant aux utilisateur·rice·s de revenir rapidement en haut de la page.

Défis avec les Web Components

Travailler avec des Web Components a apporté ses propres défis. VoiceOver est particulièrement sensible à la manière dont les bibliothèques sont implémentées. Nous avons travaillé en étroite collaboration avec l’équipe Bits UI (qui réagit très rapidement aux rapports de bugs) et avons par exemple implémenté des portails locaux pour les menus déroulants afin d’éviter des problèmes de navigation avec VoiceOver.

Gestion des annonces

L’un des défis les plus complexes a été la gestion des annonces VoiceOver lorsque plusieurs événements se produisent simultanément. Comme la mise en file des annonces ne fonctionne pas de manière fiable, nous avons soigneusement séquencé les événements et regroupé les annonces liées. Par exemple, lorsqu’un·e utilisateur·rice clique sur « Tout sélectionner » dans une liste d’options, des annonces séparées seraient normalement déclenchées pour chaque option et se remplaceraient mutuellement. À la place, nous annulons ces annonces individuelles et les remplaçons par un seul message clair qui résume la situation (tous les éléments sélectionnés ou désélectionnés, retour à la sélection prédéfinie, etc.).

Comme le chat est une SPA sans rechargement de page, il était également essentiel d’annoncer tous les changements visibles uniquement visuellement, comme par exemple le changement entre mode clair et sombre ou le changement de langue.

Flux du chat pour les lecteur·rice·s d’écran

Nous avons conçu l’expérience du chat spécifiquement pour les utilisateur·rice·s de lecteur d’écran :

• Le champ de saisie contient à la fois un placeholder et un aria-label avec le titre de la page. Cela fournit du contexte lors du chargement de la page, car le champ est automatiquement focalisé et les utilisateur·rice·s peuvent ainsi ignorer le contenu initial.
• Lorsqu’une réponse est générée, nous l’annonçons clairement afin de fournir le même retour qu’un indicateur de chargement visuel.
• Dès qu’une réponse est prête, elle est lue sans formatage Markdown (pas d’italique, pas de liens, etc.) afin de garantir un flux de lecture naturel.
• Après la lecture d’une réponse, nous indiquons que tu peux directement poser une nouvelle question ou naviguer vers les options du dernier message pour donner un feedback ou consulter les références. Nous ajoutons dynamiquement cette section interactive du dernier message à l’outline du document afin de créer un raccourci de navigation rapide.
• L’historique du chat est structuré comme une série d’articles avec des labels afin que les conversations précédentes soient faciles à parcourir.

Teste par toi-même

Tu peux découvrir ces améliorations avec Alva, le chatbot de l’administration du canton de Bâle-Ville. Essaie de naviguer avec VoiceOver (macOS) ou NVA (Windows), d’utiliser uniquement ton clavier ou de zoomer fortement sur un appareil mobile.

Un parcours continu

Notre prochain objectif est d’intégrer des tests automatisés d’accessibilité dans notre pipeline CI. Comme mentionné précédemment, les scans automatisés ne détectent qu’environ 40 % des problèmes d’accessibilité. Cela signifie que nous devons continuer à planifier soigneusement chaque nouvelle fonctionnalité et à la tester manuellement. Rien ne remplace les tests humains lorsqu’il s’agit d’accessibilité. Les outils automatisés peuvent signaler des labels manquants ou des problèmes de contraste, mais ils ne peuvent pas déterminer si une interface est réellement utilisable pour quelqu’un qui navigue avec un lecteur d’écran ou uniquement au clavier.

L’accessibilité est un parcours continu, pas une destination. Nous nous engageons à rendre LiipGPT utilisable par tout le monde et continuerons à faire évoluer notre approche sur la base des retours issus de la pratique.

Besoin d’aide pour l’accessibilité ?

Nous proposons des audits d’accessibilité pour identifier et corriger les problèmes dans tes applications. Si tu souhaites améliorer l’accessibilité de ton produit, contacte-nous, nous serons ravi·e·s de t’aider.

GovNL: de plusieurs mois à quelques minutes pour créer des sites

GovNL associe des composants Drupal open source et un design system ouvert pour faire fonctionner de nombreux sites du gouvernement néerlandais de manière accessible et évolutive. Le temps nécessaire pour créer un nouveau site passe alors d’environ trois mois à une dizaine de minutes seulement! Plutôt impressionnant, n’est-ce pas? C’est un excellent exemple de conception pensée pour la réutilisation à grande échelle.

Commission européenne: la coordination est essentielle pour passer à l’échelle

La Commission européenne gère déjà pas moins de 770 sites et investit fortement dans l’écosystème Drupal. Ce qui m’a marqué, c’est l’importance qu’elle accorde à la coordination, soit s’assurer que le bon contenu est publié sur le bon canal à travers cet ensemble de sites. Les Open Source Program Offices (OSPO) ont été mis en place pour piloter les stratégies open source tant au niveau gouvernemental qu'au sein des organisations.

Site web du canton de Bâle-Ville et Alva: modèle pour les administrations publiques locales

Juste avant midi, c’était à mon tour de présenter les différentes applications de l'IA que nous avons mis en place pour le canton de Bâle-Ville. Avec la nouvelle version de bs.ch, le canton a établi de nouveaux standards avec un design centré sur les utilisateur·rices, un accès aux contenus thématiques plutôt que basés sur la structure administrative interne et Alva, le premier chatbot basé sur l’IA pour un canton suisse. La stack repose sur des composants open source et Liip a fortement contribué à l’open source dans le cadre de ce projet. Nous utilisons Drupal comme CMS, Nuxt/Vue, l’éditeur blökkli pour le frontend headless et Elasticsearch pour la recherche. Le contenu est produit par une équipe éditoriale transversale entre départements, suivant une stratégie de contenu claire.

L’IA pour soutenir le public et les éditeur·rices du site

Cette présentation était aussi l’occasion de partager des chiffres plus de 18 mois après la mise en ligne. Aujourd’hui, Alva traite plus de 10 000 questions par mois, avec environ 1,36 question par conversation et une croissance de +44 % depuis Alva 2.0. Grâce aux intégrations API, le chatbot peut répondre à des questions en s’appuyant sur des informations en temps réel. Alva est également très utilisé par les collaborateur·rices internes du canton, en plus du grand public. Le chatbot affiche et vérifie toujours ses sources, un élément central pour instaurer la confiance.

Du côté de l’édition de contenu, blökkli travaille activement à simplifier les textes. Grâce à l’éditeur blökkli avec IA intégrée, les éditeur·rices peuvent désormais effectuer un audit de lisibilité, voir des propositions de simplification côte à côte et les accepter ou les adapter. Alva et les fonctionnalités d’IA sur bs.ch continuent d’être développées afin d’offrir aux éditeur·rices et aux citoyen·nes des technologies d’IA fiables.

Des technologies IA au sein du gouvernement français

Une autre présentation inspirante portait sur les cas d’usage de l’IA dans la plateforme Services Publics+ du gouvernement français. Avec plus de 140 000 expériences partagées et plus d’un million de réactions, le système utilise des technologies d’IA assistée pour aider les services de l’État à fournir des retours aux citoyen·nes. Ils utilisent notamment la transcription automatique de la parole (speech-to-text) et des résumés en temps réel comme technologies clés. Sacrés français:)

L’UE fait plus que jamais confiance à l’open source

L’Union européenne a introduit Website Evidence Collector, un outil open source qui analyse les sites web pour détecter des problèmes de sécurité. Il est publié sous licence EUPL (European Union Public Licence), ce qui met l’accent sur l’interopérabilité entre pays et licences et favorise la collaboration multilingue. Je me demande si la Suisse dispose d’un outil similaire.

Mais l’UE ne se contente pas de faire confiance à l’open source pour la sécurité. Avec Interoperable Europe, elle propose également un nouveau portail comprenant un Licensing Assistant très utile. Tu peux y trouver et comparer des licences logicielles et utiliser un outil de vérification de compatibilité pour voir si différentes licences open source peuvent être combinées et s’il existe des complications juridiques.

Utiliser l’open source ne suffit pas, il faut des champion·nes

Enfin, Tiffany Farris, du cabinet de conseil stratégique Palantir.net (à ne pas confondre avec la controversée Palantir Technologies), a rappelé que l’utilisation de l’open source est une bonne chose mais n’est pas suffisante. Il faut des champion·nes dans les organisations qui mettent la contribution et la santé de l’écosystème à l’agenda. Concevoir pour la réutilisation devrait être un principe fondamental. Du point de vue américain, la commande publique reste un problème: l’usage de l’open source a augmenté, mais les mécanismes de soutien n’ont souvent pas suivi. Considérer l’open source comme « gratuit » peut conduire à attribuer des contrats à des fournisseurs qui présentent leur travail comme open source sans réellement soutenir un écosystème dynamique. Elle a enfin proposé des modifications concrètes des politiques de marchés publics dans l’esprit « public money, public code », afin de mieux soutenir l’écosystème. Une conclusion vraiment inspirante pour une journée riche en apprentissages et en échanges.

Tu peux regarder la playlist des présentations Drupal4Gov EU 2026 si tu souhaites approfondir les sujets abordés.

We created a fully themeable chat UI that can be embedded in any website and has no effect on the parent page. Kanton Basel-Stadts Alva and RAMMS' Rocky AI are instances of that UI.

This blog post will show you what we learned about creating web components that do not influence the parent page. Here are the good, the bad and the ugly when working with web components.

The Good

These are the good parts of web components. They will lay the foundation for why you might use them.

Portability

Every system that can handle HTML can handle web components. A simple tag and a script will integrate it into any web framework. It doesn't even need to be a JavaScript framework.

<body>
  <your-webcomponent></your-webcomponent>
  <script src="path/to/your-webcomponent.js"></script>
</body>

Native Feel

IFrames are another way to embed UI into a page, and they are arguably easier to use. But the main difference is that web components feel more native to the page, since they directly integrate into the parent page's layout. This means you can use transparency, intrinsic sizing (size based on the web component's contents), and seamless event communication with the parent page.

Slots

With slots you can provide content that will be added at a specified point inside your web component.

In our chat UI, we used a slot to let integrators provide a custom loading spinner. This spinner needs to be visible immediately, before the full theme loads asynchronously.

Shadow DOM - Isolating Styles

A robust way to ensure that your styles do not affect the parent page is to use the Shadow DOM. Shadow DOM is a web component feature to add a boundary for styles. Styles applied inside the Shadow DOM never apply to the parent page.

Caveat: Inheritable CSS Properties

There is one exception to the isolation where CSS properties of the parent page apply to the web component.

These are the properties that pierce through the boundary:

• Inheritable CSS properties like color, font-family, line-height
• CSS custom properties like --my-var

In practice, we have found it helps to fully specify the common properties like fonts and color on every element. That way you will never be surprised by different styles on integration.

Vite

For bundling web components, we can highly recommend Vite. There are a lot of neat tricks you can apply while bundling. Here are the Vite features we used for our web component.

Inlining Assets

Vite's explicit inline handling feature allowed us to inline our external CSS files into the JS bundle.

import cssContentString from "./index.css?inline";

This feature will not only inline the raw content of the imported index.css. It will also resolve all CSS imports, apply PostCSS transforms, and even work with CSS preprocessors like SASS. While inlined CSS is not the most efficient for browsers to render, the benefit is that we can ship a single JS file.

Library Mode

The Vite library mode provides you with fine-grained control of how the bundle should behave. To enable the library mode just add the build.lib option in your Vite config.

The Bad

Not everything about web components is great though. Here are the bad parts.

SSR - Hard to Get Working

Server-side rendering will almost certainly not work. The rest of the page can still be rendered server-side, but the web component will only show up as a <your-webcomponent></your-webcomponent> tag. Its contents will only be rendered in the browser.

There is one experimental package by Lit Labs that tries to solve this, but we never tried it.

Tailwind - Not a Great Fit

Tailwind feels like a natural choice for web components, but it does not play well with them.

The core issue is twofold. First, Tailwind ships its own CSS reset (called Preflight), which overrides default browser styles. When injected into a page that does not use Tailwind, it potentially breaks the page. Shadow DOM could isolate this reset, but Tailwind is fundamentally not designed to work inside a Shadow DOM. Here is the discussion if you are interested.

There are some hacky workarounds, but we tried them and had no success getting them to work reliably.

Our recommendation is to only use Tailwind if you are guaranteed that the parent page also uses it, and then use web components without Shadow DOM.

The Ugly

Verbose Web Components API

The native web component API is verbose and hard to read. A simple counter component, for example, requires manually defining a class, attaching a shadow root, setting up innerHTML, and wiring event listeners in connectedCallback. This boilerplate adds up quickly. You can see examples of the API here.

Fortunately, web components make for a great compile target. Svelte and Vue directly support compiling to web components. React is a bit trickier, but totally doable as well. We used this approach for our chat UI, where the first iteration was built with React and the current one with Svelte.

Weird Quirks

Advanced web component features come with edge cases that no documentation warns you about. Even Svelte, which has excellent web component support, ships with a notable list of caveats.

We even hit an undocumented edge case with slots in Svelte: the bundle script must load after the component markup, or slotted content will not render. An ugly wrapper for slots fixes the problem, but quirks like this add up and slow you down.

Font Loading - Not Working Inside Shadow DOM

When authoring web components, you get into the habit of defining all stylesheet links etc. in the web component body. As you should, so they do not affect the parent page. But there is another annoying detail here: @font-face will not work when defined in the Shadow DOM. If your web component needs a custom font, you need to inject the font CSS into the parent page to make it work.

Conclusion

I do not want to end on this ugly note though. I really think there are cases where web components are the right choice, and in our case we would choose Svelte & web components again.

To help you get started, here is a Svelte starter template.