Ça a commencé sur les jeux vidéo. World of Warcraft avec la transmogrification : des heures à parfaire l’apparence d’un personnage que j’allais regarder pendant des centaines d’autres heures.

Diablo 3 aussi.

Avec les années, cet amour de la customisation a évolué vers deux rabbit holes : le linux ricing et les claviers custom. Deux univers entiers construits autour d’une même idée.

J’aime cette idée de master your craft. Et pour vraiment maîtriser ses outils, le meilleur moyen que j’ai trouvé c’est de les designer soi-même. Ils deviennent une extension de ta façon de penser. Ils rentrent chez toi.

Bon. Les thèmes de couleurs.

J’ai eu une période où je changeais de thème Zed / Ghostty en espérant tomber sur le thème définitif. Des dizaines d’essais plus tard, deux ont retenu mon attention.

Le premier : Evergarden. Il a l’équilibre de couleurs qui me plaît le plus parmi tout ce que j’ai essayé.

Evergarden est un thème Neovim créé par comfysage, maintenu aujourd’hui par l’organisation Everviolet sur GitHub. Sa base : Everforest.

Everforest, c’est l’œuvre de Sainnhe Park. Au départ, le projet s’appelait “Forest Night” : un mix de deux thèmes verts de l’époque, vim-color-spring-night et sacredforest-vim. Un point de départ, pas encore un thème à part entière.

Avec le temps, la variante dark absorbe des influences de Gruvbox Material, une autre création de sainnhe. Une variante light apparaît. En mars 2021, le nom change : Forest Night devient Everforest. Sainnhe lui-même reconnaît que le projet est devenu autre chose.

La philosophie reste la même depuis le début : du vert, mais chaud. Du contraste, mais soft. Un thème fait pour protéger les yeux pendant les longues sessions, qui marche bien avec redshift et f.lux. Plus de 4 000 étoiles sur GitHub, des ports sur des dizaines d’éditeurs.

Evergarden reprend cette palette et y ajoute ses propres couches : des variantes saisonnières (winter, fall, spring, summer), une organisation inspirée de Catppuccin, une ambiance que leur repo résume avec “cozy morning coding”.

C’est ça que j’aime. Pas juste les couleurs, l’ambiance que ça crée. C’est difficile à expliquer rationnellement. Mes yeux aiment aller là.

Le second : Flexoki, de Steph Ango, l’homme derrière Obsidian. Steph a passé des années à travailler avec des encres et des pigments, et a voulu résoudre un problème difficile : redonner la sensation du papier à un écran émissif. Flexoki est le résultat de cette recherche.

Le nom vient de la flexographie, un procédé d’impression industriel pour le papier et le carton.

L’encre sur papier est soustractive : on mélange des pigments qui absorbent la lumière. Un écran LCD ou OLED est additif : on additionne des lumières. Mélanger du bleu et du jaune en peinture donne du vert. En digital, ça donne un marron terne. Réduire l’opacité d’une couleur digitale la désature, alors qu’une aquarelle diluée reste vivante.

Sa principale référence : Solarized d’Ethan Schoonover (2011), un des premiers thèmes à avoir pensé en termes de relations de luminosité dans l’espace colorimétrique CIELAB. Steph a poussé ça plus loin avec l’espace Oklab, en augmentant l’intensité des couleurs de façon exponentielle pour simuler la vibrance des pigments dilués.

C’est le thème le plus abouti fonctionnellement que j’ai utilisé. Pensé pour la lisibilité, calibré pour la perception humaine, construit pour les sessions longues.

Du coup je naviguais entre les deux selon mon envie. Evergarden pour ses belles couleurs. Flexoki pour son accessibilité.

Tu le vois venir.

J’ai décidé de faire le mix de ces deux mondes : de belles couleurs avec un maximum d’accessibilité.

C’est là que Buisson est né.

Le nom vient de là : les couleurs d’Everforest, oui. Mais aussi parce qu’un buisson c’est accessible. On peut tomber dessus sans trop se faire mal, s’y cacher, vivre dedans je suppose. J’aurais pu l’appeler Bush, mais il fallait cette dernière pointe de patriotisme 🇫🇷

Palette

Deux familles dans la palette. Les couleurs de base d’abord, qui couvrent tout ce qui n’est pas de la syntaxe : fonds, texte, numéros de ligne, commentaires. Puis les accents, les six couleurs botaniques qui colorent le code.

Toutes les accents ont un nom de plante ou de matière naturelle. Hibiscus, sage, river moss, slate sky, thistle, ochre. C’est volontaire : chaque nom contraint les décisions futures. Si une couleur ne peut pas s’appeler quelque chose de naturel, elle n’a pas sa place dans Buisson.

Syntax highlighting

La question centrale : quelle couleur va où, et pourquoi. Probablement ce que j’ai trouvé le plus dur à faire.

Trois niveaux de lecture.

Le niveau 1, c’est la structure du langage. Keywords et strings. Les deux éléments les plus présents dans n’importe quel fichier. Du coup ce sont eux qui reçoivent les couleurs les plus chaudes : hibiscus pour les keywords (if, def, for, return), ochre pour les strings.

Le choix d’hibiscus sur les keywords vient directement d’Evergarden. Leur rose-rouge sur chaque ligne de structure crée cette chaleur enveloppante que j’aimais dans leur thème. Le code respire.

Le niveau 2, c’est la sémantique : ce que le code fait (fonctions en sage) et ce qu’il est (types en river moss). Le vert pour les fonctions, c’est une convention qu’on retrouve dans Tokyo Night, Catppuccin, la plupart des grands thèmes. Le teal pour les types, c’est architectural.

Le niveau 3, c’est le support. Opérateurs en thistle, nombres en slate sky, commentaires en fg2 italique. Les commentaires en italique c’est non-négociable : c’est la convention pour dire “c’est une note, pas du code exécutable”. Les variables n’ont pas de couleur accent, juste fg0. Si tout est coloré, rien ne ressort.

Base colors

Le premier principe : aucun noir pur, aucun blanc pur.

Les backgrounds du mode sombre ont tous un undertone olive chaud. Le plus sombre, bg0, c’est #181916. Pas #000000. Pareil en clair : le fond principal c’est #f5f1e8. Du parchemin, pas du blanc éclatant.

C’est ça qui crée l’effet papier. Un blanc pur sur fond noir crée un halo rétinien. La fatigue après quelques heures de code vient souvent de là. Ajouter une teinte chaude aux fonds réduit ça sans sacrifier la lisibilité.

Neuf tokens, de bg0 à fg0 :

Chaque token a un ratio de contraste calculé. fg0 sur bg1 donne 11.55:1, AAA selon WCAG 2.1. Les commentaires à 5.49:1, AA. Intentionnellement plus bas : un commentaire doit être lisible mais ne rivalise pas avec le code.

Accent colors

Six couleurs. Chacune existe en deux versions : une pour le mode sombre, une pour le mode clair.

Le problème classique des thèmes clairs : les accents calibrés pour un fond sombre sont trop lumineux sur fond clair. Du coup chaque couleur a sa paire, même hue, lightness ajusté pour tenir le ratio AA sur les deux fonds.

Le processus de sélection a pris du temps. J’ai rejeté le goldenrod (trop jaune), le wild clove (trop proche d’hibiscus). River moss a dû être poussé vers H=180° en mode clair pour rester distinct du sage : à faible luminosité, deux verts séparés par 59° de hue se compriment et deviennent indiscernables. Ce genre de détail, tu ne le vois qu’en testant sur du vrai code, pendant des heures.

Ports

• VS Code
• Zed
• Neovim
• Obsidian
• Ghostty
• Alacritty
• Kitty

L’architecture : un repo principal buisson-theme comme source de vérité, des repos satellites dédiés que je ne touche jamais directement, un GitHub Action qui synchronise automatiquement à chaque modification.

Chaque marketplace a ses propres contraintes. Zed exige un git submodule avec un ID qui ne contient pas le mot “zed”. Obsidian veut manifest.json et theme.css exactement à la racine d’un repo dédié. VS Code a son propre process via Open VSX.

Publier un thème, c’est plus compliqué que de le créer.

Honnêtement, je ne crois pas que Buisson soit terminé. Les thèmes de couleurs ne le sont jamais vraiment.

Ce qui est sûr : c’est la première fois depuis longtemps que je n’ai plus envie d’en changer.

Ce blog tourne d’ailleurs sur Buisson — le fond crème, les accents rouges-rosés, les couleurs de code. C’est peut-être le meilleur test qu’un thème puisse passer : qu’on l’utilise pour construire les choses qu’on aime, et qu’on n’y pense plus.

Et puis j’ai buté sur un truc qui n’avait rien à voir avec la fréquence.

Si deux utilisateurs suivent le même blog, mon architecture allait fetcher ce blog deux fois. Une fois par utilisateur. À 100 utilisateurs qui suivent tous TechCrunch, ça fait 100 requêtes vers le même flux RSS, pour récupérer exactement le même contenu.

Ça m’a paru absurde. Les gros readers fetchent une source une fois, peu importe combien d’utilisateurs la suivent. Et je voulais que Still tienne cette logique dès la v1, pas comme un refacto douloureux à 1000 utilisateurs.

Je m’attendais à devoir retravailler pas mal de choses. Peut-être ajouter une notion de “source globale” séparée des sources de chaque utilisateur, migrer les données existantes, revoir les controllers. Le genre de chantier qu’on met sous le tapis.

Sauf qu’en regardant mon schéma, j’ai réalisé qu’il était déjà bon.

Source n’a pas de user_id. Elle existe indépendamment. C’est Subscription qui fait le lien entre un User et une Source. J’avais construit ça en pensant au quota de 10 sources actives par utilisateur, pas à la question du fetch partagé. Mais le résultat est le même modèle qu’utilisent les gros readers : sources globales, abonnements individuels.

Ce qui devait changer, c’était juste la logique de création. Avant, SourcesController#create faisait ça :

current_user.sources.create(source_params)

Ça créait systématiquement une nouvelle Source, même si l’URL existait déjà en base pour un autre utilisateur. Doublon en base, et doublon de fetch côté Sidekiq.

Le create devient :

source = Source.find_or_create_by(url: source_params[:url])
current_user.subscriptions.create(source: source)

find_or_create_by cherche l’URL en base. Si elle existe, on récupère la source existante. Sinon on la crée. Dans les deux cas, on crée juste une Subscription qui relie l’utilisateur à cette source.

Le fetching RSS, dès qu’il sera branché sur Sidekiq, tournera par source, pas par utilisateur. Un blog suivi par 100 personnes sera fetché une seule fois.

Je me demande combien d’autres décisions que j’ai prises pour Still vont finir par résoudre des problèmes que je n’ai pas encore vus venir. Et combien, à l’inverse, vont me coûter cher plus tard sans que je le sache aujourd’hui.

But it was not necessary.

The problem wasn’t technical complexity. Two color palettes, adapted typography, specific transitions: that’s doable. The problem is that Sun and Moon asked the user to locate themselves in an energy level before they could read. Still was asking a question: what state are you in?

That’s not a RSS reader’s job.

So I pulled the thread. If Still refuses unread counters, notifications, gamification, because all of that imposes a posture on the user before they’ve even opened the app, then Sun and Moon do exactly the same thing. They label the moment before the reader has had a chance to exist.

What’s left: a reading feed and Flow.

The feed composes content silently. A dense article, a short one, a tech source, then something else. The alternation is there but it’s unnamed. It’s not configurable. It exists because it’s the best way to read, not because the app decided it for you.

Flow is unchanged. It’s been the only voluntary gesture in Still since the start, and it stays that way.

My understanding of “less is more” changed doing this.

Before: remove features so the interface doesn’t get crowded.

Now: remove ideas you’re proud of because they contradict what you’re building. That’s different. The first is discipline. The second is honesty.

I don’t know yet if these were the right calls. I know Still is easier to describe today than it was yesterday. And usually, when a product gets easier to describe, that’s a good sign.

L’idée : posséder moins pour apprécier plus. Ça s’applique à presque tout, le design, le code, ce qu’on crée, une semaine entière.

Concrètement : une feature en moins dans une app, celle qui ne sert pas l’objectif et perd l’utilisateur en route. Une activité en moins dans une semaine, celle qui prend trop de place par rapport à ce qu’elle apporte.

Le bénéfice est double.

D’abord on apprécie plus chaque chose qui reste. Moins de bruit autour, plus de place pour l’essentiel.

Ensuite on récupère de l’énergie. Chaque chose qu’on possède, chaque option qui existe, coûte une décision. Steve Jobs portait le même col roulé noir tous les jours, en partie pour ça. Réduire le nombre de choix sans impact, pour garder l’énergie décisionnelle pour ce qui compte.

Moins de possessions, moins de choix, moins de bruit. Plus d’attention pour ce qui reste.

Less is more n’est pas un renoncement. C’est un échange : moins de possessions contre plus d’attention disponible.

Revenir à Ruby

Je connais Ruby depuis quelques années. Le Wagon, des projets personnels, puis je suis passé à d’autres langages. Quand j’ai commencé Still, j’ai eu envie de retrouver ce langage.

Ce n’est pas une décision purement rationnelle. Ruby a une philosophie que j’aime beaucoup : le code doit être agréable à écrire et à lire, et cette agréabilité ne doit pas être un accident. Matz l’a conçu pour le bonheur du développeur. Ça se sent dans les idiomes, dans la lisibilité, dans la façon dont le code se lit quand il est bien écrit.

Du coup Rails s’est imposé naturellement. Still est une app CRUD classique : des sources, des articles, des utilisateurs, des sessions. C’est le terrain où Rails excelle. Les conventions sont fortes, l’écosystème est mature, Sidekiq pour le fetching RSS est natif à l’écosystème. Et le bottleneck d’un lecteur RSS, c’est le réseau, pas le CPU. Le GIL de Ruby ne sera jamais mon problème à cette échelle.

J’ai considéré Go et Node.js. Go m’aurait donné des performances brutes, mais un développement plus lent sans convention web. Node.js a une bonne gestion de l’I/O mais un écosystème fragmenté. Rails m’a donné ce dont j’avais besoin réelle sans friction.

Choisir React

La séparation API-only + React m’est apparue rapidement.

La voie naturelle de Rails, c’est Hotwire : des templates ERB côté serveur, Turbo pour les mises à jour dynamiques. C’est solide, ça marche et pour la majorité des apps Rails, c’est le bon choix.

Mais Still n’est pas la majorité des apps Rails ;)

Still a une exigence de précision visuelle. Chaque transition, chaque animation, chaque geste dans l’interface doit être contrôlé. Hotwire est pensé pour des apps fonctionnelles et rapides à livrer. React me donne le niveau de contrôle que l’expérience de lecture exige. L’un n’est pas meilleur que l’autre en absolu. Mais pour ce que Still veut être, le choix était clair.

Honnêtement, c’est le seul argument qui compte. Still ne choisit pas React pour être moderne. Il le choisit parce que l’expérience qu’il veut construire ne peut pas exister autrement.

Ce que je ne sais pas encore

Je rentre dans Rails 8 après quelques années d’absence. Ma compréhension des nouvelles conventions, des patterns qui ont évolué, n’est pas encore complète. Il y a des décisions que je vais probablement regretter en chemin.

C’est documenté dans le projet. Si les choix d’aujourd’hui se révèlent mauvais, au moins j’aurai la trace de pourquoi je les ai faits.

La prochaine question concrète : comment Sidekiq et le fetching RSS s’intègrent dans cette séparation backend/frontend. C’est là que l’architecture va commencer à se tester vraiment…

Nous sommes des grands singes avec des téléphones.

Des singes certes un peu plus intelligents que la moyenne, avec des outils fascinants, des angoisses élaborées et un sens aigu du regard de l’autre. Mais des singes. Des êtres sociaux, là pour une fraction de seconde à l’échelle du monde, qui se retrouvent à avoir honte de ce qu’ils font, à ne pas oser dire, à hésiter avant une décision qui est presque toujours moins grave qu’elle n’en a l’air.

La honte d’envoyer un message. L’hésitation avant une conversation difficile. La paralysie face à un choix. Le singe en face de toi, avec ses propres peurs et ses propres schémas, il improvise exactement comme toi.

Cette phrase ne supprime pas la complexité. Elle la remet à sa juste taille.

Affronter la remarque d’un collègue devient plus simple quand tu te rappelles que c’est un singe qui exprime quelque chose de sa propre confusion. Une décision difficile pèse moins quand tu intègres que, dans cent ans, la poussière de cette décision sera imperceptible. Se comprendre soi-même aussi : l’incohérence, la peur irrationnelle, le rejet. Bref, tout ce qu’on appelle “être humain” est assez logique quand on se rappelle d’où on vient.

On veut trop souvent se voir plus évolués qu’on ne l’est. Plus rationnels, plus maîtrisés. En fait, une bonne partie de ce qu’on appelle la complexité de la vie, c’est juste des singes sociaux qui naviguent leurs contradictions avec les outils qu’ils ont.

Admettre qu’on improvise n’est pas un échec. C’est ok.

Pas l’usage excessif : la vraie addiction. Recharger la page d’accueil en boucle sans avoir envie de rien en particulier, juste voir si quelque chose de nouveau était apparu. La récompense aléatoire. Remettre une pièce dans la machine, encore une fois, sans l’avoir décidé.

Aza Raskin, l’inventeur du scroll infini, dit qu’il en est malade de regrets. Il a probablement contribué à détruire des milliards d’heures d’attention humaine. Il a inventé ça en une nuit pour un projet, sans savoir ce qu’il créait.

Mais quelqu’un savait. Quelqu’un a décidé que c’était exactement ce qu’il fallait déployer.

Ces algorithmes n’ont pas été conçus par des incompétents. Ce sont les meilleurs ingénieurs et psychologues du comportement humain au monde. Chaque détail est optimisé : la durée des pauses, la fréquence des récompenses, la friction d’arrêt quasi-nulle. Ce n’est pas un accident que tu ne puisses pas t’arrêter. C’est l’objectif.

Du coup j’ai voulu construire quelque chose.

Pas une appli de bien-être. Pas un tracker de temps d’écran. Quelque chose de plus fondamental : une app de lecture où je pourrais consommer tout ce qui m’intéresse, articles, vidéos, podcasts, de façon intentionnelle. Sans algo. Sans inbox qui se remplit pendant que tu dors. Sans cette sensation qu’il faut vider quelque chose.

En cherchant comment construire ça, j’ai redécouvert les flux RSS. Technologie des années 90, toujours vivante, complètement ignorée. Minimaliste, presque belle dans sa sobriété, et visiblement faite pour durer : le web a tout changé autour d’elle, elle est restée. Chaque blog, chaque chaîne YouTube, chaque podcast expose un flux RSS. Tu t’abonnes, tu reçois le contenu dans l’ordre chronologique : aucun algorithme au milieu, aucune curation étrangère. C’est le web tel qu’il aurait dû rester.

Le problème : aucune app existante ne les présente correctement. Elles recréent toutes la même inbox anxiogène, le même compteur de non-lus, la même logique du mail à vider. Et celles qui évitent ça le remplacent par un algorithme qui décide pour toi ce que tu vas regarder. La technologie est saine. L’expérience est cassée.

Still répare ça.

L’idée centrale tient en une phrase : tu ne peux jamais être en retard dans Still.

Il n’existe pas de dette de lecture. Pas de boîte à vider. Quand tu n’ouvres pas l’app pendant trois jours, rien ne s’accumule. Elle continue à préparer tes sessions en silence. Quand tu reviens, elle est prête. Sans un mot.

Tu ouvres Still. Tu lis. L’app a préparé une sélection depuis tes sources, avec l’obsession habituelle que je met sur le design pour que l’expérience soit la plus propre possible, alternant les registres et les longueurs. Quand tu pars, tu passes en mode Flow : l’app compose une session audio, tu scannes un QR code, tu poses ton téléphone dans ta poche.

Aucun compteur. Aucune notification non sollicitée. Aucune suggestion que tu n’as pas faite toi-même.

Je construis Still pour moi. J’en ai besoin et j’ai envie de l’utiliser tous les jours. Si ça peut aider d’autres personnes à avoir une relation différente avec leur consommation de contenu, j’en serai ravi.

Ce devlog documente la construction depuis le début. Les décisions, les frictions, ce qui marche et ce qui casse. Le code est ouvert sur GitHub. Le blog a changé de direction récemment, ce projet est une partie du pourquoi.

Est-ce qu’on peut construire quelque chose qui résiste à ce que des milliards de dollars ont passé des années à optimiser ? Je ne sais pas encore. Mais ne pas reproduire les mêmes patterns me semble une bonne idée.

Steph Ango a une liste de quarante questions qu’il se pose tous les dix ans. Je suis tombé dessus par hasard.

La première : qu’est-ce que tu ferais si tu avais six mois à vivre ?

Honnêtement, celle-là ne m’a pas surpris. La réponse était évidente avant même d’avoir fini de la lire. Tu arrêtes de travailler. Tu passes du temps avec les gens que tu aimes. Tu fais tout ce que tu n’as pas encore eu le temps de faire. C’est humain, c’est universel, c’est ce que tout le monde dirait.

Mais la deuxième question était différente.

Qu’est-ce que tu ferais si tu avais un milliard ?

Là il n’y a plus de contrainte de temps. Plus d’urgence. Juste du temps, en quantité presque illimitée, sans aucune pression. Et je me suis rendu compte que ce que je voudrais faire de ce temps, c’est créer. Pas voyager indéfiniment, pas m’arrêter. Coder. Designer. Construire des expériences digitales sans la pression d’apprendre tel langage parce que les boites le veulent, sans devoir justifier mes choix techniques par un marché. Juste faire ce que j’aime, comme je l’aime.

C’est là que j’avais une dissonance.

Pas parce que les deux réponses se ressemblent. Parce que dans aucun des deux cas je ne me suis imaginé faire ce que je fais en ce moment. Pas de cloud security à apprendre pour décrocher un poste. Pas de certifications à préparer pour rassurer un recruteur. Pas de chemin raisonnable vers une liberté future hypothétique.

Juste créer. Maintenant.

Le problème que je prenais dans le mauvais sens depuis des mois.

Le mauvais calcul

J’avais une vision très précise de ce qu’était une carrière. Tu choisis une spécialité technique pointue. Tu l’apprends seul, en dehors des cours, parce que les cours ne suffisent pas. Tu accumules des compétences durement acquises jusqu’à atteindre un niveau qui te garantit un style de vie confortable, assez d’argent, assez de liberté, assez de temps pour enfin faire ce que tu aimes.

J’allais me spécialiser en cloud security exactement pour ça. Pas parce que ça me transcendait. Parce que c’est bien payé, ça s’apprend à distance, ça garantissait la liberté dont j’avais besoin pour être satisfait.

Le problème avec ce calcul : il suppose que j’arrive au niveau espéré. Et même si j’y arrive, il suppose que la liberté obtenue me laissera l’énergie et l’envie de créer ce que je voulais créer dès le départ.

C’est beaucoup de suppositions pour éviter de faire directement ce qu’on veut faire.

J’ai reconsidéré. Une carrière ce n’est peut-être pas un plan d’accès à une vie future. C’est peut-être juste ce qui se forme quand on fait ce qu’on aime avec assez d’obstination. Et même si l’opportunité ne suit pas exactement comme prévu, au moins on n’aura pas passé des années à préparer une vie qu’on ne vivra jamais vraiment.

Le signal

Ce que je veux faire, c’est créer des expériences digitales. Du design. Du logiciel. Des interfaces précises. Des choses belles qui fonctionnent exactement comme elles devraient fonctionner.

Je l’ai compris en finissant ce blog.

Pas en le publiant. En le finissant. Il y a eu un moment, tard dans la nuit, où j’ai regardé ce que j’avais construit et j’ai été ému. Pas fier. Ému. La page d’inspirations, la typographie, les espacements, le dark mode chaud. Tout semblait juste. Tout semblait moi.

Je ne pensais qu’à ça depuis des semaines. Et ce n’était pas malsain. C’était quelque chose qui m’habitait.

C’est ça le signal.

Ce qui change

Donc ce blog va changer. Pas le design, il vient d’être fait avec une obsession que je n’aurais pas pu mettre sur autre chose. Pas le niveau d’exigence. Pas la voix.

Ce qui change : tout le sujet. Ce blog sera un journal de créateur. Les projets que je construis, les choses que j’apprends, les convictions que je me forme sur le craft, le design, les langages, les outils. Ce que ça fait de créer quelque chose de bout en bout et de le finir vraiment.

Le centre de gravité, c’est créer.

Dans dix ans

Steph Ango a une autre question dans sa liste : qu’est-ce que tu espères qui sera pareil dans dix ans ?

Je n’avais pas de réponse immédiate à celle-là. Mais en écrivant cet article, j’en ai une.

L’obsession. Le fait que certaines choses m’habitent au point de ne plus penser à autre chose jusqu’à ce que ce soit fait, et bien fait. J’espère que ça ne changera pas.

Et si c’est le cas, le reste s’alignera.