Extracteur de Texte

À Propos de l'Extracteur de Texte

L'Extracteur de Texte tire les données structurées d'un texte non structuré grâce à des expressions régulières finement ajustées. Collez une facture, un fil d'e-mails, un journal de chat, une sortie de serveur ou une page web copiée et isolez instantanément chaque adresse e-mail, lien, numéro de téléphone, adresse IPv4/IPv6, hashtag ou @mention dont vous avez besoin. Les marketeurs s'en servent pour des listes de leads, les développeurs pour trier des logs, les chercheurs pour récolter des citations, les équipes de support pour parser des tickets. Tout s'exécute localement en JavaScript pour que vos contacts sensibles ne quittent jamais votre machine, et vous pouvez dédupliquer, trier et filtrer la casse avant d'exporter.

Quels motifs regex utilisez-vous pour extraire les e-mails, et quelle est la précision ?

Nous utilisons un sous-ensemble pragmatique du RFC 5322 qui correspond à ~99% des e-mails réels en rejetant la plupart des faux positifs. Le motif /[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}/g accepte les points, les plus-alias ([email protected]) et les TLD de 2 caractères (.fr) et plus. Il ne valide pas les formes exotiques comme les local-parts entre guillemets ("jean dupont"@example.com) ou les commentaires — celles-ci représentent moins de 0,01% des boîtes mail et les inclure ferait exploser la regex en quelque chose d'illisible. Pour 100% de conformité RFC il vous faudrait un vrai parser, mais pour la génération de leads, le parsing de logs ou la récolte de contacts, cette regex attrape tout ce qui est pratique et tourne en microsecondes même sur des entrées de plusieurs mégaoctets.

Comment détectez-vous les numéros internationaux — supportez-vous le format E.164 ?

Nous correspondons à plusieurs formats de manière heuristique. Le motif principal attrape l'indicatif pays optionnel (+1 à +999), les parenthèses optionnelles d'indicatif régional et les groupes de chiffres séparés par espaces, tirets, points ou rien — couvrant USA/Canada (123) 456-7890, français 01 42 86 82 00 et E.164 +33142868200. L'E.164 pur est une norme ITU-T stricte qui exige + suivi de jusqu'à 15 chiffres sans séparateurs ; nous le matchons mais acceptons aussi les variantes formatées que les gens écrivent réellement. Attention : ce motif produira des faux positifs sur les longues chaînes numériques comme les IDs de commande ou les timestamps — validez toujours les listes de téléphones extraites avec libphonenumber si la précision compte pour la facturation ou la conformité.

Pourquoi certaines URL de mon texte ne sont-elles pas extraites ?

Notre regex d'URL exige soit un schéma explicite (http://, https://, ftp://) soit un préfixe www. Les domaines nus comme exemple.com mentionnés en prose sont intentionnellement ignorés — distinguer 'j'ai visité exemple.com hier' (URL) de 'regarde mon e-mail [email protected]' (simple domaine) est impossible sans contexte, donc nous préférons moins de faux positifs. Les domaines IDN punycode (xn--80akhbyknj4f) fonctionnent. Les domaines internationalisés en écriture native (例え.jp) non, car leur détection requiert une table de recherche. Les URL se terminant par de la ponctuation (point, virgule, parenthèse) voient cette ponctuation finale automatiquement retirée, puisqu'elle appartient presque toujours à la phrase environnante et non au lien.

Y a-t-il une limite de taille d'entrée et à quelle vitesse l'extraction se fait-elle ?

La limite pratique est d'environ 10 Mo de texte — au-delà, les navigateurs commencent à brider le thread d'UI. Sur un ordinateur portable typique, extraire tous les types d'entités de 1 Mo de texte mixte prend 50-150 ms ; de 10 Mo prend 1-3 secondes. Le goulot d'étranglement est le moteur regex V8, pas la mémoire. Nous exécutons les motifs séquentiellement plutôt qu'en parallèle car les Web Workers ajoutent un overhead qui dépasse les économies pour des entrées sous 50 Mo. Si vous devez extraire de corpus énormes (échelle Go), faites-le côté serveur avec grep -oE ou ripgrep plutôt que dans le navigateur — ces outils streament les données et évitent de tout charger en mémoire d'un coup.

Puis-je extraire des entités que l'outil ne supporte pas nativement, comme des dates ou codes produit ?

Pas encore via l'UI, mais vous pouvez post-traiter la sortie 'Tous les Nombres' avec votre propre regex rapide dans DevTools ou un tableur. Demandes courantes : ISBN-13 (978-2-07-036822-8), numéros de carte bancaire (validés Luhn), adresses bitcoin (base58 avec 1 ou 3 en tête), numéros de sécurité sociale français (NIR à 15 chiffres), adresses MAC (00:1A:2B:3C:4D:5E) et IBAN. Nous évitons délibérément les cartes bancaires et le NIR pour ne pas créer un outil de moisson de PII. Si vous avez un motif spécifique que vous extrayez souvent, ouvrez une demande de fonctionnalité — ajouter une regex prend quelques minutes une fois que nous savons que le cas d'usage est suffisamment large pour justifier une case à cocher dans l'UI.

Comment la sensibilité à la casse affecte-t-elle la détection des doublons ?

Quand 'Supprimer les Doublons' est activé, nous hashons chaque correspondance dans un Set. Avec la sensibilité à la casse DÉSACTIVÉE (par défaut), nous mettons d'abord en minuscules, donc '[email protected]' et '[email protected]' s'effondrent en une entrée — généralement ce que vous voulez pour les e-mails (insensibles à la casse selon RFC 5321) et les domaines. Avec la sensibilité ACTIVÉE, la casse originale compte, ce qui est correct pour les URL (les chemins après le domaine SONT sensibles à la casse sur les serveurs Unix), les hashtags (#Bitcoin vs #bitcoin peuvent désigner des campagnes différentes sur Twitter) et les Mentions. Le toggle existe parce qu'il n'y a pas de réponse universellement correcte — les e-mails se comportent d'une façon, les chemins d'URL d'une autre, et vous devez correspondre à la convention du système qui consomme votre liste extraite.

Pourquoi l'extraction se passe-t-elle dans le navigateur plutôt que sur un serveur ?

Trois raisons. Confidentialité : e-mails, téléphones et IP relèvent souvent des données personnelles au sens de l'article 4 du RGPD — les garder côté client signifie que nous ne stockons, loguons ou traitons jamais vos contacts sur nos serveurs, éliminant tout risque de fuite. Vitesse : un aller-retour vers le serveur ajoute 50-300 ms de latence réseau que la regex locale évite totalement ; pour des flux par lots cela s'additionne. Coût : le traitement côté client passe à l'échelle de millions d'utilisateurs à coût de calcul nul pour nous, ce qui maintient l'outil gratuit pour toujours. La contrepartie est l'absence d'intelligence côté serveur (pas de reconnaissance d'entités par ML, pas de correspondance corrigée orthographiquement) — pour ces cas, des services payants comme Google Cloud Natural Language API ou AWS Comprehend sont appropriés, mais pour l'extraction de type regex, le navigateur est plus rapide, plus sûr et gratuit.