# Les données disent où les gens décrochent. Jamais pourquoi.

Un an d’actualité du financement et 100 sites arabes lus : ce que les chiffres prouvent, ce qu’ils ne prouvent pas, et l’analyse de données comme méthode de design.

https://laithjunaidy.com/fr/writing/data-says-where-not-why
Par Laith Aljunaidy. Publié: 2026-11-01.

---

![Graphique de 179 startups financées de la région MENA : 44 pour cent n’ont pas de site en arabe, et 48 pour cent des sites arabes présentent au moins un défaut qui masque l’arabe à Google ou aux robots d’IA](https://laithjunaidy.com/writing/taken-apart-2/chart.png)

*Le graphique de [Taken apart, numéro deux](https://laithjunaidy.com/fr/writing/taken-apart-arabic-100). Les bases figurent au-dessus des barres : 179 startups, 88 pages, 94 pour les robots. Cette ligne en petits caractères fait l’essentiel de cet article.*

Le 25 septembre 2026, j’ai publié [Taken apart, numéro deux](https://laithjunaidy.com/fr/writing/taken-apart-arabic-100). Sur 179 startups financées de la région avec un site vérifiable, 79 n’avaient aucune version arabe. Soit 44 pour cent.

Chaque fondateur de la région dit la même chose de l’arabe : bien sûr que nous le prenons en charge. Je voulais savoir ce que cela donne sur la page, alors j’ai cessé de demander et j’ai compté. Une liste publique, lue dans l’ordre, chaque entreprise vérifiée, aucun tri. Le commit qui a publié le résultat porte Claude comme coauteur. Le scanner, l’échantillon et les notes sur la façon dont il a été constitué ont été mis en ligne à côté de l’essai, ouverts à quiconque veut les relancer.

Ce chiffre est désormais l’exemple sous Analyse de données dans mon guide du processus de design. À la seconde lecture, la limite est là, dans le résultat. Les données disent que 53 des 67 startups financées des Émirats se présentent en anglais seulement. Elles ne disent pas un mot du pourquoi. Ni si les fondateurs l’ont décidé, oublié, n’en avaient pas les moyens, ou n’ont jamais pensé que leurs acheteurs lisent l’arabe. Chaque raison que je pourrais vous donner serait une supposition déguisée en constat.

Cet écart est toute la méthode. L’analyse de données dit où les gens décrochent. Elle ne dit jamais pourquoi. Voici comment le scan a vraiment été construit et lu, et ce qu’il apprend sur l’usage des données en design.

## L’essentiel

- L’analyse de données consiste à lire ce qui existe déjà avant de créer du neuf : analytique, ventes, tickets de support, journaux de recherche, avis d’applications, données publiques, anciennes recherches. C’est la recherche la moins chère qui soit, donc elle passe en premier.
- Elle répond à où et combien. Elle ne peut pas répondre à pourquoi. Le pourquoi vient des entretiens et de l’observation, et les données vous disent qui interroger et sur quoi.
- Fixez la source et l’ordre avant de regarder. Nous avons lu l’actualité du financement de Wamda du plus récent au plus ancien et vérifié chaque entreprise éligible à son tour. Rien n’a été choisi parce qu’il y avait des problèmes.
- Chaque chiffre porte sa base. Les mêmes 79 entreprises font 44 pour cent de 179 et 43 pour cent de 184. Les deux sont vrais. Un seul est honnête sans son dénominateur.
- Mesuré, jamais deviné. Un site illisible a été écarté de ce contrôle, et nous l’avons dit, au lieu de combler.
- L’IA rend l’analyse peu coûteuse. Le contrôle est maintenant le savoir-faire : ouvrir les lignes brutes, relancer le décompte et jeter tout pourcentage sans fichier derrière.

## Qu’est-ce que l’analyse de données en recherche UX ?

C’est lire ce qui existe déjà avant de créer du neuf. L’entrée de mon [guide du processus de design](https://laithjunaidy.com/fr/writing/design-process-checklist#data-analysis) se trouve sous Empathise et donne une raison de la faire d’abord : elle coûte le moins. Tickets de support, données de vente, journaux de recherche, avis d’applications, anciennes recherches. Vous repartez avec les endroits où regarder et les premières questions de vos entretiens.

Nielsen Norman Group appelle la famille plus large la [recherche secondaire](https://www.nngroup.com/articles/secondary-research-in-ux/), ou recherche documentaire, et dit qu’elle devrait être une première étape standard de toute pratique de recherche rigoureuse. Leur raisonnement est pratique : si quelqu’un a déjà mené une étude, utilisez-la, et ne payez pas pour redécouvrir ce que votre propre organisation a appris il y a deux ans.

![La section Analyse de données du guide du processus de design sur laithjunaidy.com : lire ce qui existe déjà, et la ligne selon laquelle les données disent où les gens décrochent et jamais pourquoi](https://laithjunaidy.com/writing/data-analysis/hub-data-analysis.jpg)

*L’entrée [Analyse de données](https://laithjunaidy.com/fr/writing/design-process-checklist#data-analysis) du guide du processus de design. Deux paragraphes là-bas. Ceci est la version longue.*

Il existe deux sortes de données que l’on peut lire ainsi.

Vos propres données sont ce que votre produit enregistre déjà : sessions, entonnoirs, commandes, boîte de support, barre de recherche que personne ne regarde. C’est là que se voit le décrochage : une étape où beaucoup arrivent et où peu repartent dans la bonne direction.

Les données publiques sont ce que le monde a déjà publié : actualité du financement, sites de concurrents, avis des boutiques d’applications, statistiques publiques. C’est ce que nous avons utilisé pour Taken apart. Personne ne nous a donné accès à quoi que ce soit. Chaque page lue était une page que n’importe quel visiteur peut ouvrir.

Les deux sortes ont la même force et la même limite. Elles consignent ce qui s’est passé. Elles ne consignent pas ce que quelqu’un voulait dire.

## Pourquoi compter plutôt que demander ?

Parce que ma question était un « combien », et que les gens répondent mal à ce genre de question sur eux-mêmes.

Si j’avais interrogé dix fondateurs sur leurs sites arabes, j’aurais entendu dix versions de « nous prenons l’arabe en charge ». C’est ce que les gens disent à voix haute, et ce n’est pas un mensonge. Pour un fondateur, une page d’accueil traduite derrière un sélecteur de langue vaut prise en charge. La question qui comptait était ce à quoi cette prise en charge ressemble pour quelqu’un qui arrive sur la page, pour Google, et pour les robots derrière ChatGPT, Claude et Perplexity. Ce n’est pas une opinion que quelqu’un détient. C’est un fait sur un serveur, et on peut aller le lire.

C’est la première règle d’usage des données en design. Servez-vous-en pour les questions auxquelles elles répondent : combien, à quelle fréquence, où, depuis quand. Servez-vous des entretiens pour celles auxquelles elles ne répondent pas : pourquoi, que cherchiez-vous à faire, à quoi vous attendiez-vous.

![La section « Quatre sur dix ignorent complètement l’arabe » de l’essai : 79 des 179 entreprises avec un site vérifiable n’ont pas de version arabe, 8 sur 66 en Arabie saoudite, 53 sur 67 aux Émirats](https://laithjunaidy.com/writing/data-analysis/taken-apart-four-in-ten.jpg)

*Le résultat tel que publié dans [Taken apart, numéro deux](https://laithjunaidy.com/fr/writing/taken-apart-arabic-100). L’essai appelle la répartition par pays « la vraie histoire ». C’est aussi exactement là où les données s’arrêtent de parler.*

## Comment avons-nous choisi ce que nous lisions ?

C’est la partie que la plupart des analyses de données sautent, et c’est elle qui décide si le résultat signifie quelque chose.

La façon facile d’écrire cet essai aurait été d’ouvrir vingt sites de startups que je connaissais déjà, de trouver les cassés et de les compter. On obtient un chiffre frappant qui ne prouve rien. On trouve ce qu’on était allé chercher.

L’ordre a donc été fixé avant d’ouvrir le moindre site. Nous avons utilisé une source publique, l’[actualité du financement](https://www.wamda.com/news) de Wamda, lue dans l’ordre de publication, du plus récent au plus ancien : 473 articles, du 23 septembre 2026 jusqu’au 30 septembre 2025. Aucune seconde liste n’a été mêlée, si bien que chaque entreprise provenait du même flux ordonné.

Un titre n’était retenu que s’il rapportait une entreprise nommée qui levait des fonds : un tour annoncé, un investissement stratégique ou une ligne de crédit. Fonds, accélérateurs, acquisitions, sorties, partenariats, lancements et mentions répétées d’une même entreprise étaient écartés. Le pays devait être l’un de neuf : Arabie saoudite, Émirats, Égypte, Jordanie, Koweït, Qatar, Bahreïn, Oman ou Maroc. Le secteur devait être l’un de : fintech, e-commerce, livraison, proptech, santé, edtech, mobilité, SaaS ou RH. Les banques agréées, les entités publiques et les entreprises connues pour avoir fermé étaient écartées.

184 entreprises ont passé les filtres. Nous les avons vérifiées dans l’ordre, bons sites et mauvais, jusqu’à ce que 100 aient une version arabe. La centième était DOO, dans l’article de Wamda du 30 septembre 2025. La règle entière est écrite dans [la façon dont l’échantillon a été constitué](https://laithjunaidy.com/writing/taken-apart-2/SAMPLE.md), publiée avec l’essai.

Trois choses de ce paragraphe font le vrai travail.

**La source est extérieure à vous.** Nous n’avons pas choisi les entreprises. Wamda l’a fait, en rapportant leur financement. Cela retire la sélection de mes mains, où elle doit être quand j’ai déjà un avis sur la réponse.

**La règle d’arrêt est fixée à l’avance.** « Jusqu’à ce que 100 aient une version arabe » est une règle qu’on peut vérifier. « Jusqu’à ce que j’en aie assez » non.

**La définition est écrite.** Version arabe signifie qu’un visiteur peut atteindre du texte arabe depuis le site de l’entreprise : un sélecteur de langue, un lien hreflang arabe, une page d’accueil arabe par défaut, ou une redirection selon la langue du navigateur. L’arabe qui n’existe que dans l’application mobile ne comptait pas. Pas plus qu’une URL arabe vers laquelle rien ne pointe, ou un sélecteur qui laisse la page en anglais. Ce sont des appréciations, et elles figurent dans les notes, où on peut les discuter.

L’échantillon lui-même est un simple fichier, [sample.csv](https://laithjunaidy.com/writing/taken-apart-2/sample.csv) : entreprise, pays, secteur, page d’accueil, l’URL arabe et l’article de Wamda qui a mis l’entreprise sur la liste. 100 lignes. Chaque ligne se rattache à l’article qui la justifie.

## Qu’a réellement contrôlé le scanner ?

Le scanner est un seul fichier, [scan.mjs](https://laithjunaidy.com/writing/taken-apart-2/scan.mjs). Le commentaire en tête liste chaque contrôle et énonce la règle sur laquelle repose toute l’étude : chaque contrôle est mesuré, jamais deviné.

![Le commentaire d’en-tête de scan.mjs : chaque contrôle est mesuré, jamais deviné, et un site impossible à récupérer est écarté du dénominateur de ce contrôle, suivi des huit contrôles exécutés](https://laithjunaidy.com/writing/data-analysis/scan-checks.jpg)

*Le début du [scanner](https://laithjunaidy.com/writing/taken-apart-2/scan.mjs) publié. Huit contrôles, chacun une question qu’un vrai visiteur ou un robot poserait à la page.*

Chaque contrôle représente une personne ou une machine qui lit la page.

| Contrôle | Ce qu’il lit | Qui il représente |
| :- | :- | :- |
| raw_ar_chars | Les lettres arabes dans le HTML serveur, scripts retirés | Les robots d’IA qui n’exécutent pas JavaScript |
| title_ar | Si le titre de la page contient de l’arabe | Un internaute arabe qui lit la ligne bleue dans Google |
| lang, dir | La langue et le sens d’écriture définis sur la page | Navigateurs, lecteurs d’écran, moteurs de recherche |
| canonical | Si la page se désigne elle-même ou une autre page comme l’originale | Google qui décide quelle page afficher |
| hreflang | Combien d’alternatives de langue la page déclare | Google qui associe les pages arabe et anglaise |
| bots | Le statut HTTP pour GPTBot, OAI-SearchBot, ClaudeBot et PerplexityBot comparé à un navigateur normal | ChatGPT, Claude et Perplexity |
| robots | Si robots.txt interdit chacun de ces robots | Les règles que le site affiche lui-même |
| overflow | De combien la page glisse latéralement sur un iPhone 13 après chargement | Une personne sur son téléphone |

Chaque requête demande l’arabe en premier, suit les redirections et abandonne après 25 secondes. Le contrôle mobile ouvre la page dans une fenêtre d’iPhone 13, attend qu’elle se charge, attend trois secondes de plus et mesure de combien la page dépasse la largeur de l’écran.

Le choix de conception qui me tient le plus à cœur est celui qui paraît le plus petit. Un site impossible à récupérer est consigné comme injoignable et écarté du dénominateur de ce contrôle. Il n’est pas compté comme cassé, ni comme correct. Il est compté comme inconnu, et les inconnus sont rapportés.

Cette seule règle explique pourquoi l’essai peut dire « sur les 88 pages arabes que nous avons pu lire en entier » plutôt que « sur 100 ». Cinq sites n’ont donné aucune page au scanner ce jour-là, quatre l’ont refusé et un ne s’est pas chargé, donc ils sont écartés des contrôles de page. Chacun s’était chargé en arabe lors de la vérification de l’échantillon, ce qui explique qu’ils y soient restés. Sept autres sont écartés des contrôles de texte : les six que l’essai nomme, dont l’adresse ne change pas avec la langue, et un qui dessine son arabe sur un canvas, donc sans texte à lire. Les bases rétrécissent, et chaque chiffre dit laquelle il utilise : 179 entreprises, 88 pages, 94 pages pour les contrôles des robots, et un autre 94 pour le contrôle mobile.

## Pourquoi chaque chiffre porte-t-il sa base ?

Parce que la base est le chiffre. Un pourcentage sans elle n’est qu’une impression.

![La section Méthode et données de l’essai : le scanner et l’échantillon sont ouverts, les pages ont été récupérées le 25 septembre 2026 comme un navigateur et comme quatre robots d’IA, et chaque chiffre indique sa propre base](https://laithjunaidy.com/writing/data-analysis/taken-apart-method.jpg)

*La dernière section de l’[essai](https://laithjunaidy.com/fr/writing/taken-apart-arabic-100#method-and-data). Chaque chiffre indique sa propre base.*

Voici un cas réel de l’étude. L’essai dit que 79 entreprises sur 179 n’ont pas de version arabe, 44 pour cent. Les notes de l’échantillon, publiées le même jour, disent que 79 des 184 avaient un site fonctionnel sans version arabe, 43 pour cent. Les mêmes 79 entreprises. Deux pourcentages différents.

Les deux sont corrects. 184 est chaque entreprise qui a passé les filtres. Quatre n’avaient aucun site que nous puissions trouver, et une a été écartée parce que son site nous bloquait depuis notre localisation, donc elle n’était vérifiable d’aucune façon. Retirez ces cinq et il reste les 179 que nous pouvions juger. Diviser par 184 garde dans la base cinq entreprises que nous n’avons jamais jugées. Diviser par 179 dit seulement ce que nous avons vu.

La même chose se produit avec les Émirats. L’essai dit 53 sur 67. Les notes de l’échantillon disent 53 sur 69. La différence tient à deux entreprises émiraties sans site trouvable. Là encore, les mêmes 53, une base différente, les deux vrais, et un seul est un énoncé sur les sites.

Personne n’aurait remarqué l’une ou l’autre différence si nous avions imprimé « 44% » seul. C’est exactement le problème. Un pourcentage nu cache chaque décision qui le fonde. La base remet la décision sur la page, où le lecteur peut la contester.

La règle à retenir, pour les rapports de recherche, les tableaux de bord et les présentations aux investisseurs : écrivez l’effectif, puis la base, puis le pourcentage. « 79 sur 179, 44 pour cent ». Si vous ne pouvez pas remplir les deux premiers, vous n’avez pas le troisième.

## L’échantillon correspond-il au résultat ?

Une bonne habitude avant de publier : contrôler le fichier publié contre l’affirmation publiée, comme le ferait un inconnu.

L’essai dit que 8 des 66 startups saoudiennes financées n’ont pas de site arabe, donc 58 en ont un. Comptez les lignes saoudiennes de sample.csv et vous obtenez 58. Il dit que 53 des 67 startups des Émirats n’ont pas de site arabe, donc 14 en ont un. Les lignes émiraties de l’échantillon : 14. Le fichier et l’essai concordent, et chacun peut le vérifier en une minute.

L’échantillon montre aussi la forme de ce qui a été compté. 28 des 100 entreprises sont des fintechs, 22 du SaaS et 14 de l’e-commerce. 58 sont saoudiennes. Toute affirmation sur « les startups MENA » tirée de ces données est en réalité une affirmation pondérée vers la fintech et le logiciel saoudiens. La répartition par secteur reflète qui a levé des fonds et été rapporté cette année-là. Le poids saoudien est la propre règle de l’échantillon à l’œuvre : la liste contenait à peu près autant d’entreprises émiraties que saoudiennes, 67 et 66, mais seule une entreprise avec un site arabe entre dans l’échantillon. Ce n’est pas un défaut de la méthode. C’est un fait sur ceux qui sont dans le fichier, et on le dit à voix haute au lieu de laisser le lecteur supposer que l’échantillon ressemble à toute la région.

Autre petite chose que montre le fichier : dans 32 des 100 lignes, la page arabe et la page d’accueil ont la même adresse. Parfois c’est une page d’accueil arabe par défaut. Parfois c’est un sélecteur de langue qui change les mots et garde l’URL, et c’est le cas que le décompte a dû écarter des contrôles de texte. Le fichier ne peut pas dire lequel est lequel. Il faut ouvrir le site.

## Qu’ont réellement trouvé les données ?

Sur les 88 pages arabes que nous avons pu lire en entier, 42 présentent au moins un défaut qui tient l’arabe à l’écart de la recherche ou des réponses d’IA. Soit 48 pour cent.

- 28 n’ont pas de hreflang, 32 pour cent. Google ne peut pas savoir que les pages arabe et anglaise sont le même contenu en deux langues. Google explique comment hreflang associe les versions linguistiques dans sa documentation sur les [versions localisées](https://developers.google.com/search/docs/specialty/international/localized-versions).
- 23 gardent un titre de page en anglais sur la page arabe, 26 pour cent.
- 9 n’ont pas d’arabe dans la page tant que JavaScript ne s’exécute pas, 10 pour cent. Pour un robot qui lit la page brute, ce site arabe est vide.
- 8 des 94 pages des contrôles de robots refusent catégoriquement un robot d’IA avec une erreur, 9 pour cent. Une seule des huit le dit dans robots.txt.
- 3 orientent Google vers la page anglaise comme originale, 3 pour cent.

La mise en page mobile, ce qu’on accuse d’habitude, était surtout correcte. 4 pages sur 94 glissent latéralement sur un iPhone.

Cette dernière ligne est la raison de compter. Le décompte a placé les défaillances ailleurs, dans les parties que personne ne voit : une balise de titre, un élément de lien, une règle de pare-feu. L’analyse de données est à son meilleur quand elle prouve que vous vous trompiez sur l’endroit où regarder.

## Où les données s’arrêtent-elles ?

Regardez les huit sites qui refusent un robot d’IA. Les données sont exactes : le robot demande la page, le serveur répond par une erreur, un navigateur normal obtient la page. Et une seule des huit le dit dans robots.txt.

Elles ne peuvent pas dire si quelqu’un l’a voulu. L’essai dit que, pour les sept autres, c’est une règle de pare-feu, pas un choix de quelqu’un. C’est la lecture la plus raisonnable des preuves : une décision qu’on voulait prendre figure dans robots.txt, et un réglage par défaut qu’on n’a jamais regardé se trouve dans le pare-feu. Mais cela reste une lecture. Le code de statut est la donnée. L’intention derrière est une déduction, et le seul moyen d’en faire un fait est de demander à l’entreprise.

Le chiffre des Émirats est dans le même cas. 53 des 67 startups financées des Émirats n’ont pas de site arabe. On peut imaginer les raisons. Leurs acheteurs sont des expatriés. Leurs investisseurs lisent l’anglais. L’arabe est sur la feuille de route. Nous n’avons jamais demandé. Chacune mène à une décision de design différente, et les données les traitent toutes comme la même ligne.

[La comparaison de NN/g entre recherche qualitative et quantitative](https://www.nngroup.com/articles/quant-vs-qual/) le dit en une ligne : les données quantitatives peuvent vous dire qu’un design risque de ne pas fonctionner, mais elles ne signalent pas les problèmes rencontrés par les utilisateurs et ne disent pas quoi changer. C’est exactement la limite de l’essai. Il se termine par une offre : « si votre site arabe figure dans les chiffres et que vous voulez savoir lesquels, demandez-moi », parce que l’étape suivante après un décompte est toujours une conversation.

## Comment lire le décrochage dans votre propre produit ?

Le scan de Taken apart utilise des données publiques. La plupart des analyses de données en design portent sur les chiffres de votre propre produit, et la forme est la même.

![Deux écrans vendeur pour Bysooq : un tableau de bord avec ventes totales, sessions, conversion et commandes, et une grille de produits avec stocks et prix](https://laithjunaidy.com/writing/design-process/bysooq-hifi.jpg)

*Un tableau de bord vendeur conçu pour [Bysooq](https://laithjunaidy.com/fr/work/bysooq), e-commerce pour l’Irak et la Jordanie. Sous le taux de conversion se trouve l’entonnoir : ajouté au panier, arrivé en caisse, sessions converties. Les chiffres sont du contenu de design, pas ceux d’une vraie boutique. C’est la structure qui compte.*

Un entonnoir comme celui-ci est la forme la plus courante des données de décrochage. Chaque étape indique combien de personnes l’ont atteinte. L’étape où l’effectif chute le plus fort est celle que vous regardez d’abord.

Voici comment je procède.

1. Écrivez la question avant d’ouvrir le tableau de bord. « Où les clients des vendeurs partent-ils entre le panier et le paiement ? » est une question. « Regardons l’analytique » est une façon de perdre un après-midi.
2. Fixez la fenêtre et la source. Une plage de dates, une source de données, choisies avant de regarder. Changer la plage jusqu’à ce que le graphique paraisse intéressant, c’est la version tableau de bord de choisir vingt sites qu’on connaissait déjà.
3. Écrivez l’effectif et la base de chaque étape. Pas « la caisse est mauvaise ». « Parmi les personnes arrivées en caisse ce mois-ci, tant ont payé. »
4. Cherchez la plus grosse chute, pas toutes les chutes. Chaque entonnoir fuit à chaque étape. Celle à étudier est l’étape où le plus de gens partent.
5. Lisez les lignes brutes derrière. Ouvrez de vraies sessions, de vraies commandes, de vrais tickets de cette étape. Les moyennes cachent la personne qui a essayé trois fois.
6. Arrêtez-vous et écrivez les questions des entretiens. Le résultat de l’analyse de données n’est pas un correctif. C’est une courte liste de personnes à qui parler et de ce qu’il faut leur demander.

L’étape six est celle que les gens sautent. L’entonnoir dit que beaucoup partent en caisse. Il ne dit pas si les frais de livraison les ont surpris, si le moyen de paiement manquait, si la page était dans la mauvaise langue ou s’ils comparaient seulement les prix. Chacun est un écran différent. Choisissez-en un sans demander et vous concevez pour votre propre supposition, avec un graphique pour la faire passer pour de la recherche.

## Que faire du pourquoi ?

Allez le chercher auprès des gens.

Sur [Wfrah](https://laithjunaidy.com/fr/writing/designing-wfrah), l’application conçue pour les éleveurs de moutons et de chèvres du Golfe, les éleveurs donnaient à voix haute la même réponse : l’alimentation coûte cher et les acheteurs paient trop peu. Si vous ne comptiez que ce que les gens disent, ce serait votre constat. Les entretiens ont montré ce qu’il y avait dessous. Beaucoup d’éleveurs ne savaient pas calculer les besoins quotidiens du troupeau à partir des équations, et accuser le marché permettait de négliger l’alimentation et la gestion. L’application contient donc un calculateur nutritionnel qui fait le calcul à leur place.

![Écrans de l’application Wfrah en arabe : évaluation du troupeau, choix d’un animal et panneau de commande](https://laithjunaidy.com/writing/wfrah/cover.jpg)

*[Wfrah](https://laithjunaidy.com/fr/work/wfrah). Le calculateur nutritionnel est né des entretiens, pas d’un chiffre.*

L’ordre de travail est simple. L’analyse de données trouve le où et en mesure l’ampleur. Les entretiens trouvent le pourquoi. Un guide d’[entretien utilisateur](https://laithjunaidy.com/store/user-interview) bâti à partir des données interroge sur la dernière fois où la personne a buté sur cette étape précise. Une [carte d’affinités](https://laithjunaidy.com/store/affinity-map) trie ce qu’elle a dit, avec une étiquette de participant sur chaque note pour relier chaque thème à une personne. Puis un [énoncé de problème](https://laithjunaidy.com/store/problem-statement) dit ce que vous corrigez et pour qui, avec le chiffre de vos données comme preuve de l’ampleur.

## Comment utiliser l’IA pour l’analyse de données sans se tromper soi-même ?

L’IA a rendu cette méthode bien moins chère. Un modèle lit mille avis d’applications en une minute, trie des tickets de support par thèmes, écrit le scraper et rédige le rapport. Les outils avancent vite. Un [Show HN pour Graphene](https://news.ycombinator.com/item?id=49927295) d’octobre 2026, une boîte à outils d’analyse de données pour agents de code, a posé la question ouverte sans détour. Les concepteurs ont demandé si un agent de code peut aujourd’hui faire l’essentiel du travail d’une équipe BI, et répondu : presque. Il leur faut une couche de contexte « pour garantir l’exactitude des requêtes ».

L’exactitude est tout l’enjeu. Un modèle qui se trompe légèrement de requête vous rend quand même un graphique assuré. Un modèle à qui l’on demande de résumer une recherche écrira volontiers « la plupart des utilisateurs » ou un pourcentage rond sorti de nulle part. Le résultat a l’air fini, et fini n’est pas vrai.

Ce qui a gardé Taken apart honnête n’était pas un modèle plus malin. C’était un ensemble de règles qui rendent le travail contrôlable, et elles valent pour toute analyse que l’IA touche.

Faites-lui écrire du code, pas des conclusions. Le scanner est un fichier qui récupère des pages et consigne ce qu’il a vu. Il ne décide de rien. Demandez au modèle le script qui compte, puis exécutez-le vous-même. Un script peut être relu et relancé. Un paragraphe non.

Faites-lui consigner les inconnus. « Mesuré, jamais deviné » figure dans les premières lignes du scanner pour une raison. Si un modèle comble une valeur manquante par une valeur probable, votre résultat est en partie donnée et en partie fiction, et vous ne savez pas quelle partie.

Exigez la base de chaque chiffre. Tout pourcentage d’un résumé écrit par l’IA reçoit deux questions : sur combien, et dans quel fichier. S’il ne peut répondre aux deux, supprimez-le. Aucune exception pour les chiffres qui sonnent juste.

Ouvrez vous-même les lignes brutes. Avant de croire un thème, lisez cinq vrais avis qui le composent. Avant de croire un décompte, ouvrez trois des sites comptés. L’échantillon de Taken apart passe ce test : les décomptes saoudien et émirati du CSV concordent avec l’essai.

Gardez l’ordre et la règle d’arrêt hors du modèle. Le modèle ne doit pas décider quels enregistrements lire ni quand s’arrêter. C’est l’endroit le plus facile pour qu’un résultat commode se glisse, et c’est une décision qui vous appartient.

Publiez la méthode si vous publiez le chiffre. Le scanner, l’échantillon et les notes d’échantillonnage se trouvent à côté de l’essai. C’est le contrôle le plus fort qui existe. Si je me suis trompé, n’importe qui peut le trouver.

J’ai écrit l’autre moitié dans [l’IA peut-elle remplacer la recherche utilisateur](https://laithjunaidy.com/fr/writing/can-ai-replace-user-research) : un modèle est bon pour rédiger, trier et lister, et mauvais pour être votre utilisateur. L’analyse de données est l’endroit où il est à la fois le plus utile et le plus dangereux, car le résultat est fait de chiffres, et les gens font confiance aux chiffres sans les lire.

## Quand ne faut-il pas commencer par les données ?

Quand il n’y a encore rien à lire, ou quand vos données comptent la mauvaise chose.

Une idée nouvelle sans produit n’a pas de sessions à analyser. Les données publiques peuvent quand même aider : sites des concurrents, avis sur le produit le plus proche, vocabulaire des gens dans les forums. Mais la recherche principale reste les entretiens, et il ne faut pas attendre des chiffres qui n’existent pas.

Six réponses à un sondage sont un indice, pas un constat. Ne calculez pas de moyennes à la décimale pour les présenter comme un résultat. Dites ce qu’elles suggèrent et allez demander.

Une métrique peut suivre le mauvais résultat. Clics, temps passé sur la page et sessions peuvent tous augmenter quand une page est confuse. Si vos données récompensent le mauvais comportement, plus d’analyse rend le problème plus précis en apparence. Décidez d’abord ce que l’utilisateur essaie d’accomplir, puis choisissez le chiffre qui le suit.

La population peut écrire dans une langue que vos outils lisent mal. Les avis arabes avec dialecte, écritures mêlées et anglais translittéré sont difficiles à trier pour des outils, et vous ne verrez pas les erreurs sans lire les avis vous-même. C’est une des raisons pour lesquelles Taken apart a compté des choses qu’une machine lit exactement, des lettres arabes et des codes de statut, et évité tout ce qui demande à un modèle de deviner le sens.

## À quoi cela ressemble-t-il la prochaine fois ?

La même méthode marche à toutes les tailles. [Taken apart, numéro un](https://laithjunaidy.com/fr/writing/taken-apart-shadcn-defaults) s’est appuyé sur GitHub plutôt que sur des sites : les 150 dépôts shadcn/ui les plus étoilés, avec la police et la couleur primaire lues dans le code. Un dépôt dont le signal était illisible était compté comme illisible, jamais deviné, ce qui en a laissé 67 avec une police lisible. 59 de ces 67 utilisent Geist ou Inter. Mêmes règles, autre source.

![Diagrammes en barres des 150 dépôts shadcn/ui les plus étoilés : 88 pour cent utilisent Geist ou Inter, 75 pour cent livrent une couleur primaire neutre](https://laithjunaidy.com/writing/taken-apart-1/chart.png)

*[Taken apart, numéro un](https://laithjunaidy.com/fr/writing/taken-apart-shadcn-defaults). Les bases sont imprimées sur le graphique : dépôts lisibles seulement, jamais de suppositions.*

Si vous voulez mener votre propre version, voici l’ordre :

1. Une question à laquelle un décompte peut répondre.
2. Une source, lue dans un ordre fixe, avec des règles écrites sur ce qui est éligible.
3. Une règle d’arrêt fixée à l’avance.
4. Des définitions écrites avant le premier enregistrement.
5. Un scanner ou une requête qui mesure et consigne les inconnus.
6. Chaque résultat sous la forme effectif, base, pourcentage.
7. Un contrôle du fichier publié contre l’affirmation publiée.
8. La méthode et l’échantillon publiés à côté du chiffre.
9. Une liste des personnes à qui vous devez maintenant demander pourquoi.

La dernière étape est celle qui transforme l’analyse en design. Le décompte vous dit que 53 des 67 startups financées des Émirats sont en anglais seulement. Il n’a demandé ni accès ni permission à personne. Découvrir le pourquoi demandera des conversations, et la raison décidera de ce que chacun devrait construire.

## Questions fréquentes

### Qu’est-ce que l’analyse de données en UX ?

Lire ce qui existe déjà avant de rechercher ou de concevoir quoi que ce soit de neuf : analytique, entonnoirs, ventes, tickets de support, journaux de recherche, avis d’applications et données publiques. Elle montre où les gens décrochent et combien sont touchés. C’est la méthode de recherche la moins chère, donc elle passe en premier, et elle se termine par des questions pour des entretiens, pas par un correctif.

### Quelle différence entre analyse de données et recherche secondaire ?

Elles se recoupent. La recherche secondaire, ou recherche documentaire, rassemble ce que d’autres ont déjà trouvé : rapports, études, anciennes recherches. L’analyse de données lit soi-même des enregistrements bruts, les chiffres de votre propre produit ou des données publiques, et compte quelque chose. Taken apart était de l’analyse de données sur des données publiques : un flux de financement lu dans l’ordre, et les pages arabes de 100 entreprises vérifiées par un scanner.

### Les données peuvent-elles dire pourquoi les utilisateurs décrochent ?

Non. Les données montrent où les gens partent et combien. Elles ne montrent pas ce qu’ils essayaient de faire, ce qui les a troublés ou ce qu’ils attendaient. NN/g dit la même chose : les données quantitatives peuvent dire que quelque chose ne fonctionne pas, mais pas quels problèmes les utilisateurs ont rencontrés ni quoi changer. Servez-vous des données pour choisir qui interroger et sur quoi.

### Comment analyser les retours clients avec l’IA ?

Donnez au modèle les retours bruts, demandez des thèmes avec chaque élément rattaché à sa source, et des décomptes avec leur base. Lisez ensuite vous-même cinq vrais éléments dans chaque thème, supprimez tout pourcentage sans effectif ni fichier derrière, et traitez le résultat comme des questions pour des entretiens. L’IA trie vite. Elle n’est pas une source de vérité.

### Quelle taille doit avoir un échantillon ?

Assez grande pour la question, et décidée avant de regarder. Taken apart a fixé sa règle à l’avance : vérifier chaque entreprise éligible dans l’ordre jusqu’à ce que 100 aient une version arabe, ce qui a demandé 184 entreprises. Un tout petit échantillon, comme six réponses à un sondage, peut rester utile comme raison d’aller parler aux gens, jamais comme constat en soi.

### Pourquoi publier le scanner et l’échantillon ?

Parce qu’un chiffre que personne ne peut vérifier est une affirmation, pas un constat. Publier [scan.mjs](https://laithjunaidy.com/writing/taken-apart-2/scan.mjs), [sample.csv](https://laithjunaidy.com/writing/taken-apart-2/sample.csv) et [la façon dont l’échantillon a été constitué](https://laithjunaidy.com/writing/taken-apart-2/SAMPLE.md) permet à chacun de relancer l’étude, de trouver une erreur ou de l’étendre. Les résultats par entreprise sont restés privés. Le schéma était le but, pas une liste de noms.