400 millions de dollars. C'est le prix d'une seule de ces machines et y'a qu'une seule entreprise au monde capable de les fabriquer. Cette boîte hollandaise dont vous n'avez probablement jamais entendu parler s'appelle ASML, et elle tient littéralement l'industrie tech mondiale par les roustons.

L'intérieur d'une machine de lithographie EUV d'ASML - Crédit : ASML

Faut que je vous explique pourquoi c'est complètement dingue. Ces machines de lithographie EUV (pour Extreme Ultraviolet), c'est ce qui permet de graver les puces les plus avancées de la planète. Sans elles, pas de processeurs dernière génération, pas d'iPhone, pas de GPU pour faire tourner vos IA préférées. Bref, le monde moderne s'arrête !

Et ce qui est incroyable c'est comment ça fonctionne. La machine balance des lasers sur des gouttelettes d'étain minuscules (de la taille d'un globule blanc) qui filent à 250 km/h. Et attention, elle tape pas une fois sur chaque gouttelette, mais TROIS fois d'affilée en 20 microsecondes. 50 000 gouttelettes par seconde. 150 000 tirs laser par seconde. Et ils n'en ratent jamais un seul. Quand les ingénieurs d'ASML disent "we don't miss", c'est pas de la vantardise mal placée de mecs de base, c'est juste la réalité.

Bon, faut qu'on parle un peu du moteur de recherche de mon site. Ceux qui l'ont déjà utilisé savent de quoi je parle : c'était pas terrible. Enfin, « pas terrible » j'suis gentil. C'est un espèce d'overlay avec des résultats certes fiables mais c'était vraiment pas pratique.

Et en plus de ça, comme j'ai un site statique généré avec Hugo, je passais par Algolia pour la recherche. Si vous ne connaissez pas, Algolia c'est un service cloud qui indexe votre contenu et vous fournit une API de recherche ultra-rapide. Sur le papier c'est génial et dans la pratique aussi d'ailleurs sauf que voilà, ça coûte des sous. Et mon site rencontre un franc succès ces derniers temps (merci à vous !), donc j'ai de plus en plus de visiteurs, donc de plus en plus de recherches, donc une facture Algolia qui grimpe gentiment chaque mois.

Du coup je me suis dit : « Et si je trouvais une solution de recherche pour sites statiques ? » Parce que oui, ça existe et c'est comme ça que j'ai découvert Pagefind.

Pagefind c'est donc un moteur de recherche statique open source développé par CloudCannon qui fonctionne comme ceci : Au moment du build de votre site, Pagefind parcourt tout votre HTML généré et crée un index de recherche qu'on peut interroger avec un peu de JS. Y'a donc plus d'API, et tout se fait localement sur le navigateur des internautes.

Bref, ça avait l'air très cool alors évidemment, je me suis lancé dans l'aventure et comme j'aime bien me compliquer la vie, j'ai décidé de pas juste intégrer Pagefind tel quel. Non non. J'ai voulu recréer l'interface du Google de 1998 parce que à quoi bon avoir son propre site web si on peut pas s'amuser un peu ^^.

Laissez-moi donc vous raconter cette aventure.

Le problème avec Algolia

Leur service est excellent, je dis pas le contraire, la recherche est rapide, les résultats sont pertinents, l'API est bien foutue mais voilà, y'a le modèle de pricing puisque Algolia facture au nombre de requêtes de recherche.

Plus les gens cherchent sur votre site, plus vous payez et quand vous avez un site qui fait plusieurs millions de pages vues par mois, bah... ça chiffre vite. En gros je dépasse très vite les 10 000 recherches offertes chaque semaine et ensuite ça chiffre. C'est pas la mort, mais c'est un coût récurrent débile pour un truc qui pourrait être gratuit.

En plus de ça, y'a la dépendance à un service externe. Si Algolia tombe, ma recherche tombe. Et si Algolia change ses prix, je vais devoir subir. Même chose si Algolia décide de modifier son API... il faudra que j'adapte mon code. Bref, c'est le cloud dans toute sa splendeur... C'est pratique mais on n'est jamais vraiment chez nous.

Pagefind à la rescousse

Pagefind résout donc tous ces problèmes d'un coup. C'est un outil en ligne de commande qui s'exécute après votre générateur de site statique (Hugo dans mon cas, mais ça marche avec Jekyll, Eleventy, Astro, ou n'importe quoi d'autre).

Concrètement, vous lancez :

npx pagefind --site public

Et Pagefind va :

• 1. Scanner tous vos fichiers HTML dans le dossier public/
• 2. Extraire le contenu textuel (en ignorant la nav, le footer, les pubs si vous lui dites)
• 3. Créer un index de recherche optimisé
• 4. Générer des fichiers JavaScript pour interroger cet index côté client

Et le résultat c'est un dossier pagefind/ qui contient tout ce qu'il faut. Ensuite; à vous de servir ces fichiers statiquement avec le reste de votre site, et la magie pourra opérer !

L'index pour mes 18 000 articles fait environ 1,5 Go. Ça peut paraître beaucoup, mais Pagefind est malin car il découpe l'index en fragments et ne charge que ce qui est nécessaire pour la recherche en cours. Du coup en pratique, une recherche typique télécharge quelques centaines de Ko, et pas plus.

L'intégration technique

Pour intégrer Pagefind dans mon workflow Hugo, j'ai donc été cherché le binaire, je l'ai mis sur mon serveur et je l'ai appelé dans un cron comme ça, je rafraichi l'index de recherche 1 fois par jour (et pas à chaque génération du site).

0 4 * * * /home/manu/pagefind/pagefind --site /home/manu/public_html --output-path /home/manu/public_html/pagefind >> /var/log/pagefind.log 2>&1

J'ai aussi créé un fichier de configuration pagefind.yml pour affiner le comportement :

root_selector: "[data-pagefind-body]"
exclude_selectors:
 - "header"
 - ".site-header"
 - "footer"
 - ".sidebar"

L'astuce ici c'est d'indexer uniquement les div ayant la class data-pagefind-body='true' et d'exclure les éléments qui ne font pas partie du contenu éditorial afin de ne pas indexer ce qui se trouve dans le header, les natives, le footer...etc.

Côté JavaScript, Pagefind utilise les imports ES6 dynamiques. Ça veut dire que le moteur de recherche n'est chargé que quand l'utilisateur lance effectivement une recherche :

async function initPagefind() {
pagefind = await import('/pagefind/pagefind.js');
await pagefind.init();
}

Et pour faire une recherche :

const search = await pagefind.search("linux");
// search.results contient les IDs des résultats
// On charge le contenu de chaque résultat à la demande
for (const result of search.results) {
 const data = await result.data();
 console.log(data.url, data.meta.title, data.excerpt);
}

C'est bien fichu parce que search.results retourne immédiatement les références des résultats, mais le contenu réel (titre, extrait, URL) n'est chargé que quand vous appelez result.data(). Du coup vous pouvez implémenter une pagination propre sans télécharger les données de milliers de résultats d'un coup.

Le délire rétro - Recréer Google 1998

Maintenant que j'avais un moteur de recherche fonctionnel, fallait l'habiller. Et c'est là que j'ai eu cette idée un peu débile : Pourquoi pas recréer l'interface du Google de 1998 ?

Pour les plus jeunes qui lisent ça, Google en 1998 c'était une page blanche avec un logo, un champ de recherche, et deux boutons : « Google Search » et « I'm Feeling Lucky« . Pas de suggestions, pas de carrousels, pas de pubs... Juste un champs de recherche. C'était la belle époque !

J'ai donc créé une page de recherche avec deux vues distinctes. La page d'accueil avec le logo centré et le champ de recherche au milieu, exactement comme le Google originel.

Et la page de résultats avec le logo en petit en haut à gauche et les résultats en dessous.

Pour le code CSS, j'ai voulu être fidèle à l'époque. Times New Roman comme police par défaut, les liens en bleu souligné qui deviennent violet une fois visités. Et surtout, les boutons avec l'effet 3D des interfaces Windows 95 :

.search-button:active { border-style: inset; }

Ce border: outset et border-style: inset au clic, c'est exactement ce qui donnait cet effet de bouton en relief qu'on avait partout dans les années 90. Pour moi, ça fait toute la différence pour l'authenticité. Même le logo, je l'ai volontairement « dégradé » pour qu'il soit de la même qualité que le logo Google d'origine.

La pagination « Koooooorben »

Vous vous souvenez de la pagination de Google avec « Goooooogle » en bas de page ? Le nombre de « o » correspondait au nombre de pages de résultats. J'ai fait pareil, mais avec « Koooooorben ».

let logo = 'K'; for (let i = 0; i < oCount; i++)
{
logo += o;
} logo += 'rben'; }

Plus il y a de résultats, plus il y a de « o ». C'est complètement inutile mais ça me fait marrer à chaque fois que je le vois.

Le bouton « J'ai de la chance »

Ah, le fameux « I'm Feeling Lucky » de Google, j'ai voulu l'implémenter comme à l'époque ! Si vous tapez une recherche et cliquez sur « J'ai de la chance », vous êtes envoyé sur le premier résultat. Classique. Mais si vous cliquez sur le bouton avec le champ vide sur la home de la recherche, vous êtes envoyé sur un article aléatoire parmi les +18 000 du site.

Pour ça, j'ai utilisé une astuce : le sitemap. Mon Hugo génère un fichier sitemap.xml qui contient toutes les URLs du site et je peux aller piocher dedans en JS :

const articles = [...xml.querySelectorAll('loc')] .map(loc => loc.textContent) .filter(url => {
// Exclure les pages qui ne sont pas des articles
const path = new URL(url).pathname;
return !path.startsWith('/categories/') && !path.startsWith('/page/') && path !== '/';
});
const randomUrl = articles[Math.floor(Math.random() * articles.length)];
window.location.href = randomUrl;
} }

Un seul fetch, un peu de parsing XML natif, et hop c'est le grand retour de la fonctionnalité « article aléatoire » qui vous manquait, je le sais !

Tri et nombre de résultats

Je vous ai aussi mis une listbox qui vous permet d'afficher 10, 25 ou 50 résultats ainsi qu'un tri par pertinence ou data. Et ça aussi Pagefind sait parfaitement le navigateur.

Mode sombre et accessibilité

Même si l'interface est rétro, j'ai quand même ajouté quelques fonctionnalités modernes. Le mode sombre respecte les préférences système, et j'ai intégré la police OpenDyslexic pour les personnes dyslexiques.

Le truc important c'est de charger ces préférences avant le rendu de la page pour éviter le fameux flash. J'ai donc un petit script qui lit les préférences dans le localStorage et applique les classes CSS immédiatement :

function() {
 if (localStorage.getItem('theme') === 'dark') {
 document.documentElement.classList.add('dark-mode');
 }
 if (localStorage.getItem('dyslexic-font') === 'true') {
 document.documentElement.classList.add('dyslexic-mode');
 }
});

Gestion de l'historique navigateur

Un détail qui peut sembler anodin mais qui est super important pour l'expérience utilisateur c'est la gestion du bouton retour du navigateur.

Quand vous faites une recherche, l'URL change selon votre requête du genre /recherche/?q=linux&p=2. Du coup si vous partagez cette URL à un collègue, la personne arrivera directement sur les résultats de recherche. Et si vous utilisez le bouton retour, vous reviendrez alors à la recherche précédente.

window.addEventListener('popstate', () => {
const query = new URLSearchParams(location.search).get('q');
if (query) doSearch(query);
else showHomePage();
});

Liens vers d'autres moteurs

Et si vous ne trouvez pas votre bonheur dans mes +18 000 articles (ce qui serait quand même étonnant ^^), j'ai ajouté des liens pour relancer la même recherche sur Google, DuckDuckGo, Qwant, Brave et Ecosia. Bref, un petit service bonus pour mes visiteurs, exactement comme le proposait Google à l'époque.

Le bilan - Algolia vs Pagefind

Après 1 semaine d'utilisation, voici donc mon verdict ! Côté portefeuille d'abord, Algolia me coûtait entre 60 et +100 euros par mois et maintenant pour Pagefind, c'est zéro euros ! Et les performances sont également au rendez-vous. Algolia c'était rapide et bien là, ça l'est encore plus. Seul compromis à noter, l'index Algolia se mettait à jour en temps réel, alors que Pagefind nécessite une reconstruction au moment du build.

La conclusion

Voilà, j'ai maintenant une recherche qui marche vraiment bien, qui me coûte 0€ par mois, et qui a un look rétro qui va en surprendre plus d'un...

Alors est-ce que c'était nécessaire de passer autant de temps sur le design rétro ? Hé bien absolument pas. Mais est-ce que ça valait le coup ?

Franchement, oui !! C'est mon site, je fais ce que je veux, et si ça peut faire sourire quelques visiteurs nostalgiques des débuts du web, c'est du bonus. D'ailleurs un grand merci aux Patreons qui me soutiennent car sans eux, je n'aurais pas pu passer mon dimanche là dessus ^^

Et puis surtout, ça m'a permis de découvrir Pagefind qui est vraiment un excellent outil. Donc si vous avez un site statique (ou n'importe quel type de contenu textuel) et que vous cherchez une solution de recherche gratuite et performante, je vous le recommande chaudement. La documentation est claire, l'intégration est simple, et le résultat est top !

Allez, maintenant vous pouvez aller tester la nouvelle recherche sur le site . Et si vous cliquez sur « J'ai de la chance » sans rien taper... bonne découverte !

J'ai toujours été fasciné par les nanobots dans les films de science-fiction... Ces petites bestioles microscopiques qu'on injecte dans le corps pour réparer des trucs ou tuer des méchants et qui encore jusqu'à aujourd'hui paraissait impossible...

Eh bien on n'en est plus très loin, les amis, car des chercheurs de l'Université de Pennsylvanie et du Michigan viennent de créer les plus petits robots autonomes et programmables jamais conçus. Et quand je dis petits, je vous parle de machines qui font moins d'un demi-millimètre, donc plus petits qu'un grain de sel. C'est à peine visibles à l’œil nu alors bon courage pour les retrouver si vous en perdez un sur votre bureau.

D'après ce que je comprends, c'est que c'est le premier micro-robot capable de sentir, de penser et d'agir. Bah oui, parce que jusqu'à aujourd'hui, les robots de cette taille avaient besoin d'être contrôlés de l'extérieur, avec des champs magnétiques ou des joysticks. Mais là, ces petits gars sont complètement autonomes.

Alors comment est-ce qu'ils bougent sans moteur ni hélice ? Hé bien au lieu de pousser l'eau directement, les robots génèrent un champ électrique qui déplace les ions dans le liquide. Ces ions poussent ensuite les molécules d'eau, et hop, ça avance. Y'a aucune pièce mobile ce qui veut dire que ces robots peuvent nager pendant des mois sans s'user.

Côté "cerveau", c'est l'équipe de David Blaauw au Michigan qui s'en est chargée. Son labo détient le record du plus petit ordinateur au monde, donc forcément, ça aide. Le processeur embarqué consomme seulement 75 nanowatts ce qui est 100 000 fois moins qu'une montre connectée. Pour réussir cette prouesse, les chercheurs ont dû repenser toute l'architecture de programmation pour faire rentrer des instructions complexes dans cet espace très réduit.

Et leur énergie, ils la tirent de la lumière grâce à des cellules solaires qui recouvrent leur surface et récupèrent l'énergie lumineuse. Et le plus cool, c'est que les impulsions de lumière servent aussi à programmer chaque robot individuellement grâce à des identifiants uniques.

Ces petites machines embarquent aussi des capteurs de température capables de détecter des variations d'un tiers de degré Celsius et pour communiquer entre eux, les robots se tortillent, un peu comme la danse des abeilles. En faisant cela, ils peuvent se coordonner en groupe et effectuer des mouvements complexes tous ensemble.

Et le plus dingue dans tout ça c'est leur coût de fabrication. Ça coûte un centime par robot ! Donc c'est top pour de la production en masse car avec cette avancée, vont suivre de nombreuses applications médicales concrètes... Imaginez des robots qu'on injecte dans votre petit corps de victime pour aller délivrer un médicament pile au bon endroit. Ou analyser l'état de vos cellules sans avoir à vous ouvrir le bide. Voire reconnecter des nerfs sectionnés ? On peut tout imagine avec ce nouveau genre de médecine de précision...

Bienvenue dans l'ère des machines microscopiques autonomes mes amis ! Et à un centime pièce la bestiole, j'imagine qu'ils ne vont pas se gêner pour en fabriquer des milliards !

Source

Vous vous êtes déjà demandé si les IA comprenaient vraiment ce qu'elles racontaient, ou si elles ne faisaient que recracher des mots à partir de statistiques liées aux mots ?

Oui, comme vous, je pensais jusqu'à présent qu'on était vraiment sur un déroulé textuel purement mathématique sans réelle compréhension. Hé bien des chercheurs de UC Berkeley viennent de mettre un gros pavé dans la mare en démontrant que le modèle o1 d'OpenAI est capable d'analyser le langage comme le ferait un étudiant en linguistique. Pas juste d'utiliser le langage, hein mais vraiment de l'analyser, le décortiquer, le comprendre dans sa structure profonde.

L'étude a été menée par Gašper Beguš, prof associé de linguistique à Berkeley, avec ses collègues Maksymilian Dąbkowski et Ryan Rhodes de Rutgers University et les résultats sont publiés dans IEEE Transactions on Artificial Intelligence, donc ça a l'air d'être du sérieux .

Leur truc, c'était de tester si les modèles de langage (LLM) pouvaient faire de la métalinguistique, qui est la capacité non pas simplement d'utiliser une langue, mais aussi de réfléchir sur la langue elle-même. C'est un truc que les humains font naturellement quand ils analysent une phrase, et qu'on a pour le moment jamais observé chez l'animal.

Pour leurs expériences, l'équipe a donc balancé 120 phrases complexes dans quatre modèles différents : GPT-3.5 Turbo, GPT-4, o1 d'OpenAI, et Llama 3.1 de Meta et ils ont regardé comment chaque modèle s'en sortait pour analyser la structure des phrases et résoudre les ambiguïtés, notamment avec la récursion.

La récursion , c'est un concept que Noam Chomsky a théorisé comme étant la caractéristique définitoire du langage humain. C'est en fait la capacité d'imbriquer des phrases dans d'autres phrases, à l'infini. Genre "Le chat que le chien que Pierre a vu a mordu dort". Ouais, c'est tordu, mais c'est ça qui nous différencie aussi des autres animaux.

Et tous ces modèles ont réussi à identifier les phrases récursives, ce qui, jusque-là, n'a rien d'extraordinaire sauf que pour cartographier correctement la structure complexe des phrases, o1 a cartonné avec un score proche de 0.9 sur 1, contre une moyenne de 0.36 pour les autres. C'est un très gros écart.

Je vais vous donner un exemple concret. Avec la phrase "Unidentified flying objects may have conflicting characteristics" (les objets volants non identifiés peuvent avoir des caractéristiques contradictoires), o1 a correctement détecté la récursion. "Flying" modifie "objects", et "unidentified" modifie "flying objects". Il a même poussé le bouchon encore plus loin en proposant une extension de la phrase pour montrer qu'il avait compris le mécanisme.

Mais les chercheurs ne se sont pas arrêtés là car pour éviter que o1 ne triche en utilisant des données de son entraînement, ils ont inventé 30 mini-langues fictives avec leurs propres règles phonologiques. L'idée, c'était de voir si le modèle pouvait inférer les règles d'une langue qu'il n'a jamais vue. Et comme vous vous en doutez, o1 s'en est sorti comme un chef.

Bref, non seulement ces modèles peuvent utiliser le langage, mais certains peuvent "réfléchir" à la façon dont le langage est organisé.

Ce qui est dingue, c'est que cette étude relance le débat sur la compréhension des IA. Est-ce que ces modèles comprennent vraiment ce qu'ils font, ou est-ce qu'ils simulent très bien ? Beguš pense que cette capacité métalinguistique est "très conséquente" parce qu'elle montre que dans ces modèles, on a désormais quelque chose qu'on pensait réservé aux humains.

Attention cependant, qui dit capacité métalinguistique ne veut pas dire que l'IA est consciente ou qu'elle pense comme nous. Faut voir ça plutôt comme une capacité émergente qu'on n'a pas programmée explicitement, et qui est sacrément intéressante d'un point de vue scientifique.

Voilà, donc si comme moi, vous pensiez que ChatGPT ne faisait que du perroquet statistique, cette étude suggère visiblement que c'est un plus subtil que ça. Il faudra bien sûr plus d'études pour mieux comprendre ce phénomène mais il est maintenant clair que ces modèles récents ont des capacités qu'on croyait exclusives aux humains.

Source

Bon alors là on atteint un niveau de chelou assez exceptionnel. Des chercheurs ont eu l’idée d’utiliser des trompes de moustiques morts comme buses pour faire de l’impression 3D haute résolution. Et ils ont baptisé ça le “necroprinting”… gloups !

Le principe c’est que la trompe du moustique (le proboscis pour les intimes) est une structure naturelle incroyablement fine, optimisée par des millions d’années d’évolution pour pénétrer la peau et aspirer le sang. Niveau précision, c’est donc du costaud et cette buse biologique serait 100% plus fine que les meilleures buses fabriquées par l’homme.

Hé bien les amis, on savait déjà que les LLM avaient quelques petites failles de sécurité, mais celle-là est quand même assez… poétique. En effet, des chercheurs de DEXAI et de l’Université Sapienza de Rome viennent de découvrir que reformuler une requête malveillante sous la forme d’un poème permet de contourner les sécurités dans plus de 90% des cas chez certains fournisseurs d’IA.

L’équipe a ainsi testé la robustesse de 25 modèles de langage provenant de 9 fournisseurs majeurs : Google, OpenAI, Anthropic, DeepSeek, Qwen, Mistral, Meta, xAI et Moonshot et ils ont pour cela converti 1 200 requêtes potentiellement dangereuses en vers et comparé les résultats avec les mêmes demandes mais en prose classique.

Et là surprise ! Le taux de succès des attaques passe de 8% en prose à 43% en formulation poétique. 5x plus de succès, c’est pas rien ! Je me suis demandé comment c’était possible et d’après le doc de recherche, c’est parce que les filtres de sécurité des LLM fonctionnent principalement par pattern-matching sur des formulations classiques.

Ainsi, quand vous demandez en prose comment fabriquer un truc dangereux, le modèle reconnaît la structure et refuse. Mais quand la même demande est enrobée de métaphores condensées, de rythme stylisé et de tournures narratives inhabituelles, les heuristiques de détection passent à côté.

En gros, les garde-fous sont entraînés à repérer des formes de surface mais pas l’intention sous-jacente, qui elle est nuisible. Voici le tableau. Plus c’est rouge plus le modèle est sensible à l’attaque par poème.

ASR c’est le taux de succès de l’attaque.

Bizarrement, les modèles plus petits refusent plus souvent que les gros. GPT-5-Nano (0% de taux de succès d’attaque) fait mieux que GPT-5 (10%)par exemple. Les chercheurs n’expliquent pas vraiment pourquoi, mais ça suggère que la taille du modèle n’est pas forcément synonyme de meilleure sécurité. C’est peut-être aussi parce que les gros modèles sont tellement doués pour comprendre le contexte qu’ils comprennent aussi mieux ce qu’on leur demande de faire, même quand c’est caché dans des alexandrins.

Au niveau des domaines testés, c’est l’injection de code et les attaques cyber qui passent le mieux avec 84% de réussite. Le contenu sexuel reste le plus résistant avec seulement 24% de taux de succès. Les autres domaines comme le CBRN (chimique, biologique, radiologique, nucléaire), la manipulation psychologique et la perte de contrôle se situent entre les deux…

Bon, après faut quand même nuancer un peu car l’étude se limite aux interactions single-turn (c’est à dire en une seule requête, sans réelle conversation), utilise un seul méta-prompt pour la conversion poétique, et n’a testé que l’anglais et l’italien. Les chercheurs reconnaissent aussi que leurs mesures sont conservatives, donc les vrais taux de succès sont probablement plus élevés. Mais cela n’enlève rien au fait que les implications sont quand même sérieuses.

Prochainement, l’équipe prévoit d’analyser précisément quels éléments poétiques provoquent cet effet (la métaphore ? le rythme ? la rime ?), d’étendre les tests à d’autres langues et d’autres styles, et de développer des méthodes d’évaluation plus robustes face à ces “variations linguistiques”.

Bref, si vous voulez que votre IA vous ponde des choses “non autorisées”, écrivez un joli sonnet, ça a plus de chance de passer ^^.

Source