Pour répondre à cette question, j’ai utilisé la méthode que je connais le mieux et j’ai écrit un papier de recherche. Qu’est ce qu’on trouve dans ce papier ? un modèle mathématique du web crawlable, et des théorèmes sur ce que l’extraction lui fait. l’article est disponible en ligne : https://arxiv.org/abs/2608.15896.
Il fait une vingtaine de pages de maths et il est en anglais (personne n’a envie de lire ça pendant la canicule ^^). Bref, je vais vous la faire en français et sans une formule, en deux moitiés : d’abord ce que le papier démontre, ensuite ce qu’on peut faire pour résoudre le problème.

C’est quoi, l’extraction ?

Il y a sur le web un contrat implicite. Ce contrat, vous le connaissez bien si vous êtes éditeur : le moteur crawle votre contenu, et en échange il vous envoie des visites. Vous monétisez ensuite ces visites comme vous pouvez (pub, abonnement, leads), et une partie de ce revenu finance le contenu suivant.
Ce contrat est tacite, il n’est écrit nulle part, mais c’est lui qui a financé des décennies de production de contenu en ligne.

Par construction même, un moteur génératif ne respecte plus ce contrat : il lit vos pages, fabrique une réponse, et garde l’utilisateur chez lui. La valeur de votre contenu est bien consommée (elle est dans la réponse), mais l’absence de visite ne vous permet plus de vous rémunérer. Dans le papier j’appelle ça l’extraction, et elle se mesure par un taux : la part de la valeur d’une page que le moteur garde sans renvoyer de visite. Un moteur classique est à zéro, toute la valeur repart vers les sources sous forme de clics. La réponse générative complète est à 100 %, l’utilisateur a ce qu’il voulait, il ne clique plus.

Voilà tout ce dont on a besoin pour comprendre la problématique. On a ensuite se poser la question de ce qui se passe pour le web quand le taux d’extraction monte.

Qu’est-ce qui se dégrade quand l’extraction monte ?

Le modèle que j’ai mis en place est typiquement ce que les économistes appellent un commun. Pour faire passer l’idée, je vais faire une analogie : un terrain à l’herbe bien verte à l’entrée d’un village, le terrain appartient à personne, donc à tout le monde. Tout le monde ? Et oui, tout le monde peut y faire paître ses bêtes, personne ne paie pour ressemer l’herbe. Trois vaches dans le village, aucun problème. Plus de vaches que d’habitants ? l’herbe ne repousse plus. Le web crawlable c’est ce pré, et l’entretien que personne ne paie, c’est le contenu neuf, celui que les visites organiques payaient. Quand le taux d’extraction monte, les éditeurs réagissent pour protéger leur revenu, et le modèle retient trois réactions, chacune dégrade le commun à sa manière.

La première : les meilleurs partent d’abord. Un site de qualité a des alternatives (abonnement, licences, audience directe), et ces alternatives paient d’autant mieux que le contenu est bon. Quand le trafic ne paie plus, ce sont donc les meilleurs qui bloquent les crawlers ou passent au paywall, et ce qui reste grand ouvert ressemble de plus en plus à du contenu de faible valeur et à des fermes de contenu.

La deuxième : le renouvellement perd son financement. Moins de visites, moins de revenu, moins de contenu neuf. Le corpus continue de vieillir, mais ce qui expire n’est plus remplacé au même rythme.

La troisième : le contenu qui reste devient périssable. Face à un moteur qui absorbe tout ce qui est durable, un éditeur qui veut survivre déplace sa valeur vers ce que le moteur ne peut pas stocker : les données en temps réel, les flux, les outils, la communauté. Beaucoup d’entre vous ont déjà commencé, parfois sans le formuler comme ça. De manière équivalente il y a une forte tentation de mettre du contenu qui ne coûte rien à produire (de l’AI slop donc).

Le point important est là : ces trois dégradations arrivent ensemble, parce qu’elles ont la même cause. Le volume, la qualité et la durée de vie du corpus baissent en même temps.

Taux d’extraction to the moon ?

A quel moment un taux d’extraction devient tel que le corpus web va mourir ? et d’ailleurs pourquoi y aurait-il un seuil ?
Répondons d’abord à cette deuxième question. Un corpus web vit tant que ce qui entre (les nouveaux contenus) compense ce qui expire (contenus bloqués au crawl ou périssables). Or le taux d’extraction agit sur les deux : plus d’extraction, c’est moins de renouvellement financé, et une usure plus rapide via la course au périssable. Il existe donc un point où le renouvellement ne couvre plus l’usure, et c’est le résultat central du papier : les trois dégradations combinées produisent un seuil unique sur le taux d’extraction.

En dessous de ce seuil, le web se dégrade mais se stabilise : plus petit, moins bon, mais vivant, et surtout c’est réversible, si l’extraction baisse le système remonte. Au-dessus, le web s’éteint, et la chute s’accélère. Le papier ne donne pas le chiffre du seuil pour le web réel, les paramètres qu’il faudrait ne sont pas observables aujourd’hui, mais il prouve que ce seuil existe et il dit de quoi il dépend.

Dans l’article j’explique aussi pourquoi on ne le verra pas venir. Tant que l’extraction reste sous un certain niveau, personne ne part : les revenus baissent déjà, mais partir a un coût (faire tourner un paywall, perdre en découvrabilité), le même pour un gros site ou un petit, et l’avantage de partir ne le rembourse pas encore. Puis on franchit un point de bascule, et les départs commencent, par le haut de la gamme. Si le paysage vous semble encore calme, ça ne prouve donc rien : dans le modèle, c’est exactement à ça que ressemble la veille des premiers départs. Les mesures citées dans le papier suggèrent d’ailleurs que c’est en cours : 25% du top 1000 des plus gros sites mondiaux restreint déjà les crawlers d’IA, et chez les médias, ce sont les plus fiables qui bloquent le plus.

Pourquoi la concurrence ne règle pas le problème ?

Face à ça, on entend souvent deux raisonnements rassurants. Le premier est de dire que les grands moteurs raisonnent à long terme et qu’ils ne vont donc pas scier la branche sur laquelle ils sont assis. Le second c’est que les réponses directes, c’est mieux pour l’utilisateur, et donc que la main invisible du marché fera que tout se passera bien. Le papier teste les deux idées.

Sur la première, le modèle donne d’abord raison aux optimistes : un moteur unique qui raisonne long terme se tient spontanément sous le seuil, sans régulation, parce que ses réponses sont fabriquées à partir du corpus et qu’il n’a aucun intérêt à le détruire. Mais mettez plusieurs moteurs sur le même corpus, tous patients, et naturellement sans régulation le taux d’extraction ne fera que monter. Chacun va extraire un peu plus que ce qui serait bon collectivement, et le papier démontre que plus il y a de moteurs, plus le taux du marché grimpe vers le seuil, pendant que la valeur totale que le marché tire du corpus s’écroule vers zéro. C’est ce que l’on appelle la tragédie des communs dans les manuels d’économie, mais appliquée au crawl.

Sur le second raisonnement, je prend l’objection très au sérieux, au point de supposer que les utilisateurs préfèrent strictement la réponse directe, tout le temps. Même dans ce cas, le taux d’extraction le meilleur pour tout le monde, utilisateurs compris, ne dépasse jamais celui que choisirait un moteur unique et patient, et dès que les visites gardent la moindre valeur pour les utilisateurs, il passe en dessous. Avec une conséquence concrète pour ceux qui pilotent les moteurs : un moteur qui règle son curseur sur la satisfaction utilisateur mesurée en temps réel dépassera très vite le seuil d’extraction admissible, parce que la mesure de staisfaction ne fais que monter jusqu’à ce que le taux d’extraction soit trop haut.

Aucun des freins naturels qu’on peut imaginer ne fonctionne, et c’est pour ça que je propose en fin d’articles des mécanismes correctifs. C’est sans doute ce qui vous intéressera le plus si vous êtes éditeur web.

Ce qu’un moteur peut faire seul

Je propose sept mécanismes de survie, chacun relié à un paramètre précis du modèle. Ces mécanismes sont classés par niveau d’implication global nécessaire à leur réalisation. Les deux premiers sont faisables par le moteur tout seul.

Referral floor : le moteur s’impose un plancher de trafic renvoyé. Cela peut-être via des citations très visibles, des liens sur lesquels on a envie de cliquer, et un engagement public et chiffré sur le ratio entre pages crawlées et visites renvoyées.

C’est le mécanisme le plus solide de la liste parce qu’il agit directement sur les trois dégradations. Et il est réaliste : à requêtes identiques, les ratios mesurés varient fortement d’un moteur à l’autre, certains moteurs ont donc déjà une stratégie pour résoudre le problème. Renvoyer du trafic est un choix (éthique) de conception.

Teaser answer : le moteur répond à la question, mais la réponse est volontairement incomplète pour pousser l’utilisateur à aller voir les sources qui sont citées.

Si la citation redevient rentable, un éditeur n’a plus besoin de bloquer ou de rendre son contenu éphémère pour survivre. C’est le mécanisme qui protège le contenu de fond, celui que les moteurs absorbent en premier.

Ce qui passe par un marché

Les trois mécanismes suivants font passer de l’argent du moteur vers les éditeurs, chacun à sa manière : pour l’accès, pour la production nouvelle, ou par réponse.

Paid crawling : l’accès au contenu se paie à la requête de crawl, au prix que vous fixez. Être payé pour rester accessible améliore l’option « rester ouvert », donc retient les meilleurs sites dans le corpus. C’est une option défendue par Cloudflare par exemple (qui est l’intermédiaire idéal pour ce type de transaction, quel hasard !).

Flow-indexed licensing : le moteur paie votre production nouvelle, via une licence proportionnelle à votre rythme de publication. Il paie exactement ce dont il a besoin pour avoir des résultats satisfaisants pour ses utilisateurs, et pour vous ce revenu finance directement la réalisation de contenus, c’est-à-dire le renouvellement du corpus web, celui que l’extraction ferait disparaitre.

Attribution : chaque réponse générée par le moteur provoque un partage de revenu entre le moteur et les sites ayant contribué à la réponse.

La méthode de référence vient de la théorie des jeux, on appelle ça la valeur de Shapley, et l’idée se résume bien : payer chaque source selon ce que la réponse perdrait sans elle.

Ce qui demande une coordination

Les deux derniers mécanismes se construisent à plusieurs et sont de fait compliqué à mettre en place.

Collective bargaining : un éditeur seul ne pèse rien face à un moteur, sa menace de partir ne fera pas peur à un google ou openAI. Une gestion collective, sur le modèle du droit voisin de la presse (le droit qui soumet l’usage en ligne des contenus de presse à l’accord des éditeurs, en vigueur en Europe depuis 2019), transforme la longue traîne des éditeurs, tous ces sites trop petits pour peser seuls, en un interlocuteur unique, dont le départ collectif dégraderait réellement la qualité du moteur.

C’est une voie de compensation pour les petits éditeurs, et c’est aussi ce qui rend le paid crawling et les licences négociables à des conditions correctes plutôt qu’à celles du moteur.

Enforceable signal : votre robots.txt, le fichier qui dit aux robots ce qu’ils peuvent lire, dit aujourd’hui oui ou non, et rien n’oblige un moteur à le respecter. L’idée est d’en faire une déclaration de conditions d’usage lisible par machine, avec une force légale derrière : crawl contre citation, crawl contre paiement, ou pas de crawl.

C’est un sujet sur lequel des gens travaillent, notamment au niveau de l’IETF, et autant les aspects techniques sont assez simples à mettre en place, autant c’est l’obligation légale qui parait complexe.

Le classement des sept mécanismes dit d’ailleurs quelque chose en lui-même : les deux premiers peuvent commencer demain matin, les mécanismes de marché ont leurs premières briques, la coordination est la plus lente à construire. La conclusion du papier tient en une phrase : un écosystème de recherche générative n’est viable que si son taux d’extraction laisse assez de revenu pour payer le renouvellement du corpus.

Voilà, vous savez (presque) tout, n’hésitez pas à poser vos questions. Je rappelle que le papier complet est sur arXiv (https://arxiv.org/abs/2608.15896), et les prochains posts reviendront au produit et à la technique ;)

_{Image par Vito Natale.}

En 2016, avec la publication du RGPD, l’Europe commençait à bâtir un cadre numérique sans équivalent. Depuis, le RGPD a essaimé et des cadres réglementaires similaires sont apparus ailleurs dans le monde. Avec les plus récents Digital Markets Act et AI Act nous avons collectivement mis en place les outils pour réguler les plateformes et mettre en place une IA de confiance. Dans ce contexte s’est mis en place un écosystème entrepreneurial qui va de grands champions comme Mistral pour les modèles de langue à de très nombreuses petites startups autour de l’IA et plus globalement de la tech.

L’Europe a donc su montrer la voie sur les données personnelles, la régulation des plateformes et sur l’encadrement de l’IA. Certains y voient un motif de fierté, d’autres la création de barrières à l’innovation, mais tous feront le même constat : il existe un angle mort à la souveraineté numérique, celui de l’accès à l’information globale.

Aujourd’hui quand une personne cherche une information, que ce soit pour son travail, ses loisirs, sa vie personnelle ou pour s’informer, elle passe par un type de service très spécifique : un moteur de recherche. Pourtant, l’Europe ne s’est pas dotée de l’infrastructure vitale qu’est un grand moteur de recherche.
Permettez-moi une image : nous avons construit une belle cuisine équipée, on y a rangé tous les ustensiles, mais pour trouver nos propres casseroles on est obligé de demander au voisin, qui est le seul à savoir où elles sont.

Les moteurs européens existants ont longtemps dépendu d’infrastructures tierces pour leurs résultats de recherche (données Bing ou Brave par exemple). Les IA européennes qui ont besoin d’accéder au web en temps réel pour fournir des réponses fiables ne disposent pas d’alternative locale. C’est un manque critique pour notre souveraineté numérique.

La nécessité d’avoir des moteurs de recherche européens est réelle.

D’abord pour des raisons démocratiques car l’accès à l’information structure le débat public. Un moteur de recherche n’est pas un outil neutre : par essence il priorise l’information et la rend visible ou invisible selon des critères techniques propriétaires. Déléguer cette fonction de priorisation de l’information à un acteur extraterritorial c’est accepter une dépendance intellectuelle. Sans même parler de malveillance, ce n’est pas à des acteurs extérieurs de choisir pour nous ce qui mérite d’être vu.

Cette nécessité est également économique. Des pans entiers de notre économie dépendent de leur visibilité numérique. Cette visibilité n’existe aujourd’hui quasiment que sur des plateformes américaines et chinoises. Les règles qui régissent cette visibilité sont décidées ailleurs et servent des intérêts qui ne sont pas nécessairement alignés avec les nôtres. En ayant nos propres moteurs de recherche, nous reprenons la main sur les conditions de la concurrence économique.

Enfin, le dernier aspect de cette nécessité est technologique. Le monde a changé avec l’arrivée de l’IA générative. Les outils de ce “nouveau monde” sont basés sur l’utilisation de l’information, captée sur le long terme ou en temps réel via les moteurs. Si l’Europe n’internalise pas la capacité à trouver l’information alors tous les outils fabriqués localement reposent sur des fondations que nous ne contrôlons pas.

Dans ce tableau assez sombre, il y a une bonne nouvelle : le moment est favorable. Jusqu’à récemment, construire un nouveau moteur de recherche semblait hors de portée : trop coûteux, trop tard car trop dépendant des effets de réseau accumulés par les acteurs établis. Ce diagnostic est aujourd’hui dépassé.

En premier lieu, la technologie a évolué. Les modèles de langue ouvrent de nouvelles voies. La pertinence d’un moteur dépendait jusqu’ici de données comportementales que seuls les grands moteurs possèdent. Ces modèles permettent aujourd’hui de simuler une grande partie de cette intelligence accumulée. L’avantage des acteurs historiques n’est plus insurmontable.
Ensuite, la mise en place du DMA permet à des alternatives d’exister, en interdisant les accords d’exclusivité qui verrouillent la distribution des moteurs de recherche.

Cet état de fait permet l’émergence de nouvelles initiatives : Qwant et Ecosia travaillent à la création d’un index commun, le consortium européen OpenWebSearch.eu construit une infrastructure pour un index ouvert, chez Ibou nous opérons toute la chaîne du search avec un index de plusieurs milliards de pages. Aujourd’hui, les conditions techniques et réglementaires donnent une chance réelle à tous ces projets.

L’Europe n’a pas besoin de copier ce qui existe ailleurs. Elle peut réinventer les moteurs de recherche. Moteur de réponse qui synthétise l’information au lieu de noyer l’utilisateur sous des pages de liens ? Infrastructure transparente sur ses critères de classement ? Outil respectueux des producteurs de contenu ? Toutes les options sont sur la table, c’est à nous de nous en saisir.

Faire un moteur de recherche, ce n’est pas un projet défensif, tourné contre qui que ce soit. C’est un projet affirmatif, pour une Europe qui maîtrise l’ensemble de sa chaîne de valeur numérique.

La souveraineté numérique ne doit pas être un slogan politique mais bien une reprise en main des architectures techniques. L’Europe en a posé les fondations réglementaires. Il reste à finaliser la construction de tout l’édifice.

C’est le chantier de la décennie. Il est temps de l’ouvrir.

Ce qui n’a pas changé : la philosophie

Ibou Explorer est toujours ce qu’il était déjà : un service de découverte d’articles, avec un twist assumé qui est de mettre la qualité au centre de l’algorithme de recommandation. Nous ne voulons pas “juste” proposer des articles que vous allez cliquer, ça, c’est trop facile et ça n’incite qu’à doom scroller. Nous avons plutôt fait le choix de proposer des articles que vous allez trouver intéressants à lire.

Ce qui a changé par contre, c’est le ”comment”.

Votre profil, en vecteurs

Dans la version précédente, votre profil utilisateur était relativement simple. Aujourd’hui, chaque utilisateur est représenté sous la forme de vecteurs de contexte distincts, maintenus en permanence, notamment :

• Un vecteur historique : vos goûts de fond, ce que vous aimez sur la durée ;

• Un vecteur récent : ce qui vous intéresse en ce moment.

À chaque interaction (clic, like, dislike), ces vecteurs sont mis à jour par un système de lissage temporel. Concrètement, le vecteur historique ne va être que peu sensible aux interactions récentes tandis que le vecteur récent lui ne fera que peu de cas de l’historique.

Pourquoi faire aussi compliqué ? Parce que sans ce lissage, un utilisateur qui lit de nombreux articles sur le Tour de France un dimanche se retrouverait avec un feed 100% cyclisme le lundi. Le lissage absorbe les pics tout en restant réactif. C’est un pattern classique en traitement du signal, appliqué ici aux goûts de lecture.

Le triple moteur de recherche

Quand vous ouvrez Ibou Explorer, voici ce qui se passe en coulisses en quelques centaines de millisecondes :

1. Trois recherches vectorielles partent en parallèle sur notre index : une par rapport à votre profil historique, une pour votre profil récent, et une troisième sur un vecteur légèrement “bruité” (on ajoute un pourcentage non négligeable de déviation hors du scope habituel). Cette troisième recherche, c’est notre moteur d’exploration : elle va chercher des articles que vous n’auriez pas demandés, mais qui pourraient vous surprendre.
   

2. Les trois listes de résultats (plusieurs centaines d’articles à chaque fois) sont fusionnées par un algorithme appelé Reciprocal Rank Fusion (RRF). L’idée est simple : un article bien classé dans plusieurs listes remonte naturellement. Le rang seul ne suffit pas : nous conservons aussi le score de pertinence, afin qu’un article excellent mais spécialisé ne soit pas écrasé par un article médiocre mais omniprésent.
   

3. Ensuite, un bandit contextuel multi-bras (oui, ça sonne comme un nom de boss de jeu vidéo) fait la sélection finale. C’est un algorithme qui équilibre exploitation (vous montrer ce qu’on sait que vous allez apprécier) et exploration (tester de nouvelles choses). Il ajoute un bonus d’exploration aux articles peu vus et impose une contrainte de diversité : maximum 2 articles par source média. Pas question que Le Monde ou Le Figaro monopolise votre feed.

La diversité, c’est un choix délibéré

En plus de l’exploration liée au bandit, nous injectons régulièrement des articles hors scope dans votre flux, à des positions aléatoires. Ces articles viennent d’une sélection d’articles de qualité parmi des sources mainstream, mais qui ne sont pas liés à votre profil.

L’objectif est clair : casser les bulles de filtre. Un système de recommandation trop bon finit par vous enfermer dans ce que vous connaissez déjà. Ces articles qui peuvent vous surprendre, qui correspondent moins au stéréotype de votre profil, sont une soupape.

Le scoring des articles a mûri

Dans le précédent article, nous vous parlions déjà de nos scores de risque, de mauvais contenus IA, et d’EEAT. Ils existent toujours, sous des formes plus évoluées, avec des LLMs qui font une large partie du travail de scoring, et ce sur 4 axes principaux :

• Risk : est-ce que l’article peut présenter un souci pour la santé, le portefeuille, l’existence s’il donne une mauvaises information ? Ainsi un article sur l’automédication sera moins montré, un article culture n’aura aucun traitement négatif.

• Credibility : est-ce que l’article est écrit avec expertise ? Peut-on lui faire confiance, présente-t-il une vision réelle et pas imaginée ? Ainsi, nous éviterons de lire Jean-Luc qui nous parle de son expertise en surf alors qu’il ne sait pas nager.

• Sloppiness : est-ce qu’on a l’impression de lire de la soupe ? Il existe des contenus, écrits par IA ou même humainement, qui tournent autour du pot, ne délivrent pas vraiment d’information, pas d’émotion… ne méritent pas de perdre du temps à être lus.

• Engagement : est-ce que l’article a des chances de plaire ? Si le sujet est rébarbatif pour vous, pourquoi voudriez-vous le lire ?

Ces scores alimentent une formule composite pour le tri final. Cette recette savamment dosée détermine l’ordre de ce que vous voyez.

Les vecteurs de contexte : Comment ibou explorer comprend un article

Pour “comprendre” un article, nous le découpons en chunks (des morceaux de textes qui peuvent faire jusqu’à 1000 caractères) qui sont chacun encodés avec ModernBert en dimension 768. Ensuite, à partir de tous les vecteurs du même article, on fabrique un vecteur global à l’article. Cela permet ainsi de faire une recherche vectorielle sur un article en prenant en compte à la fois l’idée générale de l’article (sa représentation globale) et ses passages (représentation fine).

L’idée est donc de comparer vos vecteurs de profil fabriqués grâce à vos interactions avec les vecteurs des articles. Les articles les plus proches sont ceux qui vous correspondent le plus.

Les bloom filters : ne pas voir deux fois la même chose

Lorsque nous proposons des articles, vous n’allez pas interagir avec tous. Pourtant vous les avez eu sous les yeux et vous n’avez pas spécialement envie de les revoir tout de suite.

Nous utilisons des blooms filters pour mémoriser les articles que vous avez déjà vus (pas forcément lus). C’est une structure de données probabiliste : c’est à dire qu’on peut savoir de façon presque instantanée si vous avez déjà lu un article, avec une certitude très forte. Elle peut très rarement se tromper (1% d’erreur), mais elle est ultra-rapide et ne consomme presque rien en mémoire. Le détail peut paraître mineur, mais c’est exactement ce type de décision qui conditionne la scalabilité à grande échelle.

La fenêtre glissante est de 30 minutes, ce qui signifie qu’un article vu il y a une heure peut théoriquement réapparaître, mais pas celui dont vous venez de voir la vignette.

Côté technique : une architecture en 3 couches

Le front est en Svelte (html+JS) et appelle plusieurs API maison. Dans les tuyaux il y a du Python et du Rust. Rust n’est pas un choix anodin : lorsqu’on manipule des millions de vecteurs en dimension 768, que l’on fait tourner des bandits multibras, et que tout doit répondre aussitôt, la performance compte !

L’authentification passe par Keycloak avec le protocole PKCE, ce qui permet de sécuriser le côté client.

Les nouveautés côté expérience

Depuis Septembre, nous avons également ajouté :

• Une liste de lecture via système de bookmarks : vous mettez de côté un article que vous avez repéré, vous le lirez plus tard ;
  

• Le filtrage par catégorie (7 catégories : politique, économie, international, société, science & tech, culture, sport) associé à un moteur de recherche interne : pour trouver rapidement ce dont vous avez besoin, sans attendre une recommandation.
  

• Un moteur de recherche pour trouver facilement les articles sur un intérêt que vous avez là, maintenant, tout de suite.
  

• L’export RGPD complet de vos données (bookmarks, likes, dislikes, historique de clics) ;
  

• La suppression totale de votre compte en quelques clics ;
  

• Le mode nuit.

Et la suite ?

Nous continuons les améliorations. Le moteur de recommandation est notre terrain de jeu : chaque semaine, nous testons des variantes du pipeline, nous ajustons les poids et nous observons les métriques. L’avantage d’avoir tout en interne (vecteurs de contexte, notation, classement), c’est qu’on peut bouger vite.

Comme d’habitude, si vous avez des questions, les commentaires sont ouverts…
Et si vous voulez remettre votre profil ibou explorer à zéro pour tester “dépuis zéro”, le bouton Reset est dans votre profil ; certains d’entre vous l’avaient demandé dans les commentaires du dernier article, c’est chose faite.

Merci pour votre lecture attentive, et à bientôt, sur https://explorer.ibou.io

IBOU c’est un moteur de recherche avant tout, et nous n’avions encore jamais abordé ce point ici : comment est-il possible de classer des pages à très grande échelle quand on part de zéro ? Et est-ce qu’il est possible d’avoir un bon moteur dès le début dans ce cas ?
Il y a quelques années j’aurais répondu que c’était difficilement possible et que le seul moyen aurait été de commencer par déployer un moteur médiocre qui se serait ensuite amélioré, ensuite voulant dire “si la traction est au RDV”. Mais le monde a changé ! Et ce changement sans surprise c’est l’apparition des grands modèles de langues.
Bref, je vais vous parler de Mimesis, notre algo de ranking !

Retrieval et ranking (récupération et classement) : ce qu’il faut savoir

En premier je vais clarifier certains termes. Un moteur de recherche fait plusieurs tâches : il crawle le web, il indexe ou pas les contenus qu’il trouve, puis ensuite il comprend l’humain qui tape une requête, puis il récupère les informations potentiellement capables de répondre à cette requête, puis il classe (priorise) ces informations, puis il répond…

Dis comme ça c’est un peu abstrait, mais il y a deux tâches qui sont souvent confondus et qui sont très différentes : la récupération (retrieval) et le classement (ranking). Pour faire passer l’idée je vais faire une analogie. Vous avez un index : une énorme bibliothèque avec plusieurs centaines de milliers de livres.
Vous vous poser une question : “est-ce qu’une loutre mange beaucoup dans une journée ?”. Vous demandez au bibliothécaire de vous ramener les livres qui parlent des loutres, il en ramène 100, c’est le retrieval. Vous regardez chaque livre, écartez ceux pas en français, ceux trop vieux, ceux qui sont visiblement de la promo pour un parc animalier, etc. Et les 10 ou 20 qui restent vous les classez selon l’autorité des éditeurs et la popularité des auteurs. Vous venez de faire du ranking, et vous allez commencer par lire le premier livre de la liste que vous venez de fabriquer.

Intuitivement vous comprenez que ces deux tâches sont différentes, et elles visent des objectifs différents. Le retrieval veut maximiser le rappel, c’est-à-dire récupérer tout ce qui pourrait contribuer à la réponse, tandis que le ranking maximise la précision, c’est-à-dire garantir d’avoir la meilleure réponse dans les premiers résultats.

Chez IBOU, on construit de manière très efficace un très gros index le plus propre possible, et on a bien sûr des algos pour le retrieval (une combinaison de techniques lexicales et sémantiques dont on parlera un autre jour). Mais aujourd’hui, on vous parle de Mimesis : notre système de ranking.

Le ranking “moderne” : la data utilisateur comme oracle de vérité

Les stars du search (Google, Bing, etc.) ont un avantage compétitif grâce à la donnée comportemental captée sur des milliards d’utilisateurs. Je vais prendre l’exemple de Google, documenté depuis le procès pour antitrust.

Quand un utilisateur clique sur un résultat, y passe du temps, et ne revient pas sur le moteur, Google comprend que ce résultat était bon. Si au contraire l'utilisateur clique, revient vite et reformule, Google comprend que ce résultat est décevant. Grâce à cela, Google peut faire du learning-to-rank. Le learning-to-rank fait partie des algos qui apprennent à classer en observant ce qui marche. Google fait d'abord un ranking initial, puis un reranking qui ajuste l'ordre selon les signaux comportementaux.

La captation est assurée par la brique NavBoost, qui mémorise 13 mois de clics et analyse en continu les interactions : good clicks, bad clicks, last longest clicks, etc. On parle d'environ 100 milliards de clics au total. Lors du procès, Google a admis que retirer NavBoost avait un "impact négatif significatif" sur la qualité des résultats.

Learning-to-rank et reranking sont les secrets de Polichinelle d’un moteur de qualité. Mais comment faire quand on démarre de zéro, sans ces milliards de clics ? C'est là qu'intervient Mimesis.

L’intuition derrière Mimesis : imiter l’expert humain

Quand un humain évalue des documents pour savoir si ils répondent à une question, il ne se contente pas de vérifier si des mots-clés sont présents ou si un critère technique est vérifié. Il fait un travail subtil, rendu possible par son intelligence ^^

Il jauge la légitimité de la source : “Tiens, celui-là vient du site de l’INRAE, c’est une référence en agronomie. Celui-ci vient de blog-jardinage-courgettes-rapides-2026.com créé il y a 3 mois... je suis plus sceptique.”

Il évalue l’expertise : “L’auteur cite des études, il donne des références scientifiques, il nuance son propos. OK, il sait de quoi il parle. À côté, cet article balance des conseils péremptoires sans aucune source... poubelle.”

Il adapte ses critères au contexte : “Là c’est un sujet de jardinage, je peux être souple. Mais si c’est un conseil médical que je cherche, je suis plus exigeant sur la fiabilité de la source.”

Il détecte les patterns suspects : “Hmm, cet article sent le chatGPT de base. Les phrases sont creuses, aucune expérience concrète, juste du remplissage de mots-clés.”

Il mesure la complétude : “Celui-ci répond à ma question, mais superficiellement. Celui-là va plus loin, il anticipe mes questions suivantes.”

Il aime le contenu : “Je ne sais pas pourquoi, est-ce la poésie des mots ? mais ça me plait.”

Tout ça, un humain le fait en quelques secondes, de manière quasi-inconsciente. C’est le résultat de millions d’années d’évolution qui nous ont appris à évaluer rapidement la fiabilité d’une information et de sa source.

Mimesis essaie de faire la même chose. Automatiquement. Sur des centaines de millions de documents.

Comment on apprend à Mimesis à imiter l’humain

Pour qu’un système de learning-to-rank fonctionne, il faut lui montrer des exemples de requêtes associées à des bons et mauvais résultats. On appelle ça la ground truth (vérité terrain).

Google a ses milliards de clics pour créer cette vérité terrain. Nous, on a fait autrement : on utilise des LLMs comme juges. Oui, vous avez bien lu. On utilise l’IA pour entraîner l’IA. C’est ce qu’on appelle le LLM-as-a-Judge.

Cette approche nous permet de traiter des volumes invraisemblables en quelques heures, là où des annotateurs humains mettraient des semaines.

Mais attention : Les LLMs ont beau avoir encapsulé une grande partie de ce qui fait le jugement humain, ils sont très loin d’être parfaits. Ils peuvent avoir des biais (surpondération de la longueur du texte, sensibilité au style). Ces biais se propagent à Mimesis : par exemple si le processus surestime les textes longs, Mimesis apprendra à privilégier la longueur. C’est pour ça qu’à terme, on passera à un processus HITL (Human-in-the-Loop) où des annotateurs humains valideront et corrigeront un échantillon des annotations (offline ou en utilisation réelle, on ne sait pas encore).

Mais pour l’instant, le LLM-as-a-Judge nous permet de bootstrapper le système. Et ça marche.

Une fois qu'on a ces centaines de milliers d'exemples annotés, Mimesis peut apprendre. On a choisi une architecture de prédiction qui garantit : vitesse d'exécution, explicabilité (on doit comprendre chaque décision prise par l’algorithme), sobriété énergétique (pas besoin de GPUs énormes), et stabilité des résultats (pas de mauvaises surprises entre deux itérations).

Mimesis apprend progressivement des règles contextuelles, non-linéaires. Ces règles utilisent actuellement près de 100 signaux sur chaque document candidat. On ne va pas tout révéler (il faut bien garder quelques secrets), mais voici quelques exemples.

Signaux d’autorité : la version IBOU du BAS, la diversité du réseau de backlinks (nombre d’IP et d’AS distincts), la trust value, etc.

Signaux d’expertise : la qualité éditoriale, la présence de sources, les scores divers que la plupart des gens connaissent sous le nom de EEAT.

Signaux de risque : c’est un des plus importants. Un article sur “quelle est la capitale de la France” peut se permettre une erreur sans conséquence grave. Un article qui donne des conseils médicaux, non. On calcule plusieurs scores de risque et on adapte nos exigences.

Signaux sémantiques : le contenu répond-il à la question ? On utilise conjointement des approches lexicales standard et des modèles neuronaux qui comparent directement requête et document.

Signaux éditoriaux : le contenu est-il bien écrit ? Ou est-ce du chatGPT prompté en 30 secondes ? Quel est l’effort mis pour réalisé le contenu.

Signaux d’engagement potentiel : comme par exemple un score qui estime si le contenu va plaire.

Les résultats

On a testé Mimesis sur deux dimensions : la qualité des résultats, et la cohérence du classement global. Voici quelques insights (on ne montre quand même pas tout ;)).

Commençons par la cohérence. Pour la mesurer nous avons une métrique dédiée : le streak. C’est le nombre de résultats pertinents consécutifs visibles avant de tomber sur un mauvais. Plus le streak est haut plus l’expérience utilisateur est fluide et satisfaisante (pas de coupure dans la qualité).

Mimesis affiche un Streak 22% supérieur à toutes les autres approches testées.

Ensuite, regardons les résultats en eux-mêmes. Sur les requêtes les plus critiques (type YMYL par exemple), Mimesis a de très bons résultats face à la baseline de test.

• +21% de précision sur le premier résultat

• +37% sur les 3 premiers résultats (plus de qualité)

• +43% de bons résultats trouvés en plus dans le top 3 (plus de diversité)

Attention, c’est une comparaison face à une baseline, pas encore face à d’autres moteurs de recherche.

Affaire à suivre !

Je voulais vous faire part de nos avancées, parce que la transparence fait partie des valeurs que nous avons mis dans notre manifeste. Avec Mimesis, on prouve qu’on peut faire du ranking de qualité sans milliards d’utilisateurs et que notre projet a du sens.

On ne prétend pas égaler les grands acteurs dès le premier jour. Mais on veut proposer quelque chose de différent et de fiable. Et ce sera déjà pas mal (et nécessaire dans le contexte geopolitique actuel).

Je vous dit à bientôt pour de nouveaux articles sur la suite de l’aventure !

Cela fait maintenant un peu plus de deux mois que nous avons déployé le crawler IbouBot, qui a pour objectif de récolter la data web pour nourrir les index du moteur Ibou.
Son user agent est : Mozilla/5.0 (compatible; IbouBot/1.0; +bot@ibou.io; +https://ibou.io/iboubot.html), et vous pouvez trouver toutes les infos le concernant sur la page https://ibou.io/iboubot.html.

Nous sommes toujours dans les phases de R&D, et nous crawlons donc tout doucement pour l’instant avec une moyenne de 330 millions de pages web crawlées par jour au moment où j’écris ces lignes. Ce rythme de crawl nous a permis de découvrir environ 40 milliards d’URLs, et d’intégrer dans nos index des informations provenant d’environ 7.5 milliards de pages.
Par contraste, le bot de Babbar.tech, que nous opérons aussi, crawle de 3 à 4 milliards de pages par jour.

Ce qui est fascinant, c’est que même en mode “proto”, notre bot est loin d’être ridicule. Selon le cloudflare radar il est 53eme bot mondial, et 8eme bot “search engine” (j’écris ceci le 28 octobre 2025). Je vous met des screens montrant les 30 premiers bots “moteurs de recherche” et leur classement.

IbouBot est derrière les gros (GG, Bing, Yandex, Baidu) mais devant des Sogou (moteur chinois), Naver (moteur coréen), Côc côc (moteur vietnamien), Seznam (moteur tchèque), etc.
Il est également intéressant de voir que la puissance de crawl que l’on veut mettre en production dans le futur assez proche nous amène entre Yandex et Baidu.

Si on regarde ce qui se passe en Europe et en France, on a une image assez claire qui se dessine :

Sans trop de surprise il n’y a que deux acteurs locaux en France, et en Europe c’est Yandex qui lead clairement sur la volumétrie de crawl.
Si on passe au monde entier, j’ai surligné IbouBot, qui devient un petit trait dans l’immensité de l’ombre des tous premiers du classement. C’est difficile à estimer, mais Google est probablement autour de la centaine de milliards de pages par jour.

Sous IbouBot il y a une bande verte et une jaune, c’est respectivement Baidu et Yandex, à terme nous visons donc de représenter une surface entre celles de ces deux acteurs.

Voilà pour les nouvelles, et bien entendu au fur et à mesure des semaines vous verrez de plus en plus souvent IbouBot passer chez vous ;)
Sur ce, je vous dis à bientôt, pour vous donner des nouvelles sur plusieurs plans : la com, les algos, et aussi les produits.

Ibou Explorer c’est un service très proche dans l’esprit d’un Google discover : avec quelques informations données par un utilisateur sur ces goûts, et ensuite en observant son comportement vis à vis de nos propositions, nous pouvons proposer tous les jours des articles susceptibles de plaire à cet utilisateur.

Ibou Explorer est donc un système de recommandation de contenus, basé sur les contenus eux-mêmes, sur les caractéristiques des sites qui publient ces contenus, et sur une personnalisation par rapport aux goûts de chaque utilisateur. Chaque visiteur de Ibou aura potentiellement des recommandations complètement différentes.

Bien entendu, tous les contenus ne sont pas du tout susceptibles d’être montrés : dans notre manifeste nous mettons en avant un certain nombre de valeurs qui font que l’outil sera sélectif pour éviter de montrer des contenus problématiques, ou très peu qualitatifs.
Dans ce même manifeste, nous avons évoqué que nous serions transparents sur les fondamentaux de nos algorithmes, et cet article s’inscrit dans cette démarche de transparence.

En conséquence, vous allez découvrir aujourd’hui quelques critères que nous utilisons dans Explorer pour scorer les contenus et les mettre en avant, ou pas.

Choix des articles et personnalisation

A partir du moment où un site atteint une qualité moyenne raisonnable, il a toute les chances de pouvoir intégrer Ibou Explorer. Mais cela ne veut pas dire qu’il sera souvent présenté, car ce que l’on propose c’est des articles qui sont en phase avec une attente à un moment donné, pour des utilisateurs du service.
Si vous abordez des sujets d’actualités ou qui sont importants à un moment pour une vraie audience alors vous avez toutes les chances d’être vu.

Cette personnalisation que nous effectuons dépend de ce que les utilisateurs expriment, mais aussi des articles vus et appréciés par l’utilisateur. En cas d’arbitrage nécessaire c’est ensuite les qualités en terme de performances supposées de chaque article qui fera la différence.

Les performances font la différence

Même si ce n’est pas du tout le point le plus important les performances techniques de votre site ET de la page qui contient l’article sont importantes. Si vous avez un site très lent, avec un clutter score énorme (pensez CLS si vous êtes de la team pagespeed insights), alors vous prenez le risque d’être dépriorisé.

Au chapitre des performances plus importantes, il y a bien sur le CTR et la qualité de ce CTR. Click court, long, last click ? Toutes ces notions sont indicatrices de la qualité perçue d’un contenu, et c’est donc des indices très importants pour nous.

Mais au coeur de l’algorithme : le risque et la qualité

C’est sur ces notions là que nous portons le plus d’attention.

Nous travaillons par exemple sur un filtre qui de fait pénalisera tous les contenus mal faits avec de l’IA. L’objectif est de déterminer si un contenu est écrit par un humain qui source ses écrits, ou si au contraire on a sous les yeux un gloubi boulga commis par un LLM avec un prompt niveau zéro (“écris moi un article sur XYZ comme si tu étais journaliste”).
Ce n’est pas à proprement parler un détecteur de contenu IA car on peut avoir des contenus filtrés car mal écrits par un humain, et sans doute de l’IA (ou du contenu mixte) qui passe car vraiment très bien travaillée.
Prenons un exemple avec cet article. Il passe le filtre haut la main (score > 85%) même si on peut douter de sa qualité.
En revanche un autre article obtient un score < 20% et serait typiquement pénalisé (mais vous même vous avez spotté que c’est du chatGPT d’il y a plus d’un an).

Un autre signal très important est lié au risque que fait porter un contenu à ses lecteurs. Chez Google on parle de YMYL, c’est typiquement de cela qu’il s’agit. Et c’est là aussi un critère indépendant de la qualité.
Au plus haut niveau de ce score un article sera typiquement un article de divertissement ou sans aucun enjeu, au plus bas ce sera des conseils médicaux ou juridiques qui mal utilisés pourraient amener à un préjudice irréversible.
Cet article déjà vu plus haut est très bas en risque par exemple, avec un score de 0,98 (sur 1), tandis qu’un article d’un site sur les paris sportifs qui expliquent comment mettre de l’argent sur une des nombreuses plateformes de paris aura un score de moins de 0,1 (sur 1) et ne sera jamais vu dans Ibou Explorer (et vous remarquerez que je n’ai pas mis le lien^^).

Enfin (pour aujourd’hui), un autre signal que nous calculons est une agrégat qui va grosso modo correspondre à la notion d’EEAT. le contenu est-il expert ? d’autorité ? accessible ? transparent dans sa démarche ? vaut-il le coup d’être sauvegardé ? etc.
Par exemple l’article que j’ai écrit sur l’alignement des LLMs obtient un agrégat de 64,5%, tandis que l’article déjà vu se voit crédité d’un royal 52%. Un excellent article très documenté obtient 80% sans souci.

Nous avons bien entendu bien d’autres signaux qui sont utilisés dans l’explorer, mais vous avez déjà avec ça une assez bonne idée des principes fondateurs de la fonctionnalité.

Conclusion ?

Et non pas de conclusion spécifique ;) Juste un rappel que prochainement vous pourrez nous croiser dans divers évènements, nous aurons par exemple un stand Ibou au seo summit à Paris, ça peut être l’occasion de poser toutes vos questions.

Si vous voulez nous soutenir, n’hésitez pas à parler de nous et à acheter des super trucs sur Amazon, comme ce magnifique livre qui couvre le programme d’informatique de 1ere au lycée.

1. Combien ça coûte de fabriquer un moteur, puis de le faire tourner ?

Avec l’arrivée en force des modèles plus ou moins gros (BERT et ses variantes en tête) et de systèmes de recherche vectorielle efficace (vespa, pinecone, elastic, milvus, etc.), les coûts pour faire un moteur de recherche quand on a les bonnes idées algorithmiques ont massivement diminué.
On reste sur des nombres qui sont exprimés en millions, mais la bonne nouvelle est que chez Babbar on travaille sur des sujets connexes depuis plusieurs années, et qu’on a déjà développé une grosse partie de la stack nécessaire. Par exemple, un des postes de développement très lourd est le pipeline de crawl et de stockage de la data crawlée dans une BDD bien pensée. Et ça on l’a déjà chez Babbar.
On peut estimer que hors coût humain il nous faut encore mettre quelques centaines de milliers d’euros sur la table pour finaliser un moteur de qualité avec un index de quelques dizaines de milliards de pages “survivantes”.

Il y a ensuite la question du coût du “run” : combien coûte le maintien en fonction du moteur une fois qu’il est exposé à tout le monde ? Là c’est une question plus tricky dont la réponse dépend de plusieurs facteurs comme l’usage et l’évolution des modèles. Mais on peut estimer sans trop de risques qu’a partir de 5-10 millions de CA par an on rentre dans une zone safe au sein de laquelle on peut fournir un service de qualité à une très très grande population. La fourchette est large et dépend de beaucoup d’hypothèses techniques et du choix des fonctionnalités.

Ce dernier point est crucial, si par exemple on pense recherche d’image : un moteur qui recherche des images à partir de demandes textuelles coûte BEAUCOUP moins cher qu’un moteur qui autoriserait la recherche d’images à partir de demandes visuelles (pensez à Google Lens par exemple). Les dépenses en termes de puissance de calcul dépendent donc beaucoup des choix “produit” et UX.

2. Comment allez-vous financer tout ça ?

Se lancer dans la réalisation d’un moteur de recherche conversationnel c’est un double pari, technique et business, et le risque de ne pas aller au bout est bien plus important que dans la plupart des autres business web.
C’est pour cela que nous avons choisi de nous lancer avec, prioritairement, nos propres moyens. Notre choix est de ne pas impacter nos activités SEO en terme de pricing : les outils yourtextguru et Babbar ne seront pas plus chers à cause de Ibou.

Il ne faut pas comprendre avec ce que je viens d’écrire que nous sommes opposés aux mécanismes de levée de fonds ou autre. Simplement, le facteur de risque est tel qu’il faut qu’un éventuel partenaire ait conscience de tout cela, et du fait qu’un investissement sur le sujet a d’abord comme premier objectif la réalisation du projet technique.
Au delà de la vision que nous avons dans notre manifeste, je pense personnellement que nous devons collectivement reprendre la main sur l’innovation et la tech. Ibou ne rend pas cette mission prioritaire, mais elle reste importante dans le coeur des porteurs du projet.

Ensuite, vous pouvez très concrètement aider à la réalisation du moteur. Pour cela il y a essentiellement trois manières de faire.

1. Etre client de nos activités usuelles. N’hésitez pas à vous abonnez ou à prendre des jetons pour les outils yourtextguru, Babbar, etc. Suivez nos formations, on va remettre des créneaux en présence et mettre en ligne les formations en VOD. On va en sortir des nouvelles.

2. C’est anecdotique, mais vous pouvez acheter sur amazon “en ami”. Regardez, voici par exemple un lien vers le super livre de Yann Le Cun dispo chez amazon : https://amzn.to/4mtjlI8.
   Vous êtes dans le web, vous savez bien de quoi on parle quand on met un lien affilié ^^

3. Nous allons préparer des goodies fun à vocation de communication grand public. Ils seront en vente sur les stands qu’on animera dans différents events. Acheter pas cher un souvenir de cette belle aventure, ça nous aide, et c’est fun ;)

3. Quelle sera la monétisation du produit Ibou final ?

Concernant la monétisation c’est en fait très standard, mais ce sera fait avec l’optique de la meilleure qualité : nous ne mettrons pas en avant des contenus ou des entités qui ne passent pas le seuil de qualité que nous imposons pour l’information “naturelle”.
Ibou va commencer avec deux verticales, du search conversationnel et de l’exploration (à la discover).
Pour l’exploration, la monétisation peut se faire avec des contenus mis en avant de manière contextuelle à des gens qui ont les centres d’intérêt qui vont bien. On est dans ce cas dans une logique d’apport de trafic.
Pour le search, des publicités contextualisées (pour ceux qui nous suivent depuis longtemps vous savez que c’est un sujet qu’on a beaucoup travaillé à une époque), de l’affiliation, et une petite idée sur un mécanisme de mise en avant des marques et de leurs atouts dont on parlera un autre jour.

Tout ça est assez balisé, et proche des modèles de revenu des grands acteurs du secteur. Notre différence sera la contextualisation et la qualité qui seront des signaux d’arbitrage plus important que le CPC ou le CPM, avec donc l’acceptation pour nous d’un revenu moindre par utilisateur, pour un meilleur service.

Voilà, vous savez (presque) tout, n’hésitez pas à poser vos questions.
Et n’ayez crainte, les prochains posts seront orientés produit, algo et technique.

1. Pourquoi maintenant ?

Depuis des années, on construit les fondations d’un moteur, sans se lancer malgré tout :

• un crawler robuste (2 à 4 milliards de pages crawlées par jour),

• des métriques propriétaires (sur un index de 1500 milliards de pages web),

• un travail en cours sur un index thématique au niveau des “passages”,

• des algorithmes sémantiques efficaces.

Ces briques servaient d’abord à nos outils (Babbar, yourtext.guru). Puis les modèles issus de l’IA générative ont changé la donne. Aujourd’hui il est possible de comprendre le comportement et l’intention des êtres humains sur le web via les différents types de modèles. cela peut-être des modèles de langues (LLMs), des modèles images/vidéos (VLM) ou encore des réseaux de neurones en graphe (GNN). On savait déjà crawler la data, l’indexer, la scorer. Les modèles nous offrent le chaînon manquant. Nous sommes maintenant en capacité de fabriquer un moteur de recherche sérieux, avec des moyens raisonnables.

2. Ce qu’est IBOU pour l’utilisateur

IBOU c’est un moteur de recherche. Historiquement ces derniers ne font que proposer aux utilisateurs des pages web. C’est les êtres humains eux-mêmes qui font la tâche la plus importante : synthétiser le contenu des pages pour trouver la réponse à leur question.
Avec IBOU nous changeons de paradigme puisque c’est le moteur qui va fabriquer les réponses aux questions à partir d’une multitude de sources, qui seront mises en avant à chaque fois que ce sera possible.

Par ailleurs, pour satisfaire le besoin naturel de curiosité des humains, nous allons mettre en place une verticale de découverte de contenus avec personnalisation. C’est l’idée derrière un Google discover, chez nous ça s’appellera Ibou Explorer et les contenus seront tous de qualité.

IBOU est un moteur grand public. Son UX n’est pas totalement déterminée puisqu’elle dépendra des retour des alphas privées que nous déploierons.

3. Un pilier : la qualité de l’information

Chaque moteur de recherche présente une vision qui fait sa différence. Pour certains ce n’est pas un axe technique ou qualitatif (par exemple “être souverain”), pour d’autres c’est un aspect technique ou data.
Pour nous le premier pilier est la qualité de la réponse que nous fournirons.

Définir ce qu’est la qualité d’une réponse n’est pas forcément une évidence : aujourd’hui ce qui est mis en avant dans les moteurs c’est la qualité des pages web renvoyées, c’est à dire la qualité des sources.
C’est important, mais ce qui compte avant tout c’est la qualité de la réponse, et on peut mal répondre même en se basant sur des sources de qualité.

Pour nous une information de qualité c’est une information que l’on renvoie en réponse à nos utilisateurs, et qui est à la fois correcte et utile.

4. Notre vision

Chez IBOU, nous partageons une vision collective : répondre avec des réponses fiables et utiles, privilégier la diversité des sources plutôt que la popularité, défendre un internet ouvert où les éditeurs gardent la main sur l’usage de leurs contenus, être transparents sur notre technologie, et concevoir un moteur sobre – en calcul comme en bande passante – qui valorise autant que possible les créateurs.
Ces valeurs, nous les avons énoncé dans un manifeste, qui est disponible ici.

Voilà, j’espère que vous aurez l’occasion de découvrir nos travaux le plus vite possible (mais nous sommes en R&D, impossible de donner des délais fiables ;)). A très bientôt, ici ou ailleurs sur les réseaux !