Pourquoi le traitement des NFS-e brésiliennes coûte
plus cher que ne le pensent les équipes financières

L'impôt le plus simple, le processus le plus éclaté

L'ISS a une seule mission : prélever la taxe sur les services à un taux de 2 % à 5 % et reverser la recette à la ville où le prestataire est basé. Pas de système de crédit, pas de tableau de taux interétatique, pas de débat destination-vs-origine dans les trois quarts des cas. Pourtant, traiter une NFS-e — en extraire les données dans un tableur, les rapprocher d'un fichier fournisseur, valider le montant de la taxe — est une opération qui brise toute automatisation par modèle dans les 5 570 municipalités.

La plupart des équipes AP découvrent cet éclatement progressivement. Cela commence par une simple NFS-e d'un cabinet de conseil IT à São Paulo. Les champs sont clairs : CNPJ do Prestador (identifiant fiscal du prestataire), numéro de NFS-e, base de calcul de l'ISS, taux d'ISS, montant de l'ISS. Quelqu'un les saisit dans un tableur. Ça marche. Puis une autre NFS-e arrive d'un cabinet d'avocats à Rio de Janeiro. Les mêmes champs existent, mais ils sont disposés différemment — le CNPJ du prestataire est dans une barre latérale, le détail de l'ISS est réparti sur deux encadrés, le code de service est libellé autrement. Puis une troisième arrive de Belo Horizonte. Et une quatrième de Porto Alegre. Chaque document contient le même type de données. Aucun ne les présente de la même manière.

Le problème n'est pas que les données de la NFS-e soient illisibles. C'est que ces données refusent de converger vers un format unique — et la loi a été conçue pour qu'il en soit ainsi.

C'est là que la plupart des analyses sur la complexité des factures brésiliennes se trompent. Elles traitent l'éclatement de la NFS-e comme un problème technique — un défaut d'interopérabilité qu'une API middleware ou une norme XML nationale finira par résoudre. Ce n'est pas le cas. C'est un problème juridictionnel, ancré dans la Constitution fédérale brésilienne de 1988, qui a accordé à chaque municipalité l'autonomie fiscale sur sa propre taxe sur les services. L'éclatement de la NFS-e n'est pas un inconvénient temporaire. C'est la structure voulue du fédéralisme fiscal brésilien, et elle précède la facture numérique de deux décennies.

LC 116/2003 : La loi qui a créé 5 570 systèmes fiscaux

Pour comprendre pourquoi la mise en page des NFS-e varie selon les villes, il faut remonter du document à la loi qui l'a autorisé. En 2003, le Brésil a promulgué la Lei Complementar 116/2003 (Loi Complémentaire 116) — le texte fédéral définitif régissant l'ISS. La LC 116 a fait deux choses simultanément. Premièrement, elle a établi un cadre national : une liste d'environ 40 catégories de services, un taux plancher de 2 %, un taux plafond de 5 %, et des règles générales déterminant quelle ville perçoit l'impôt dans quel scénario. Deuxièmement — et c'est la clause opérante pour les équipes AP — elle a laissé chaque municipalité libre d'adopter sa propre législation dans ce cadre.

Ce n'était pas un oubli. La Constitution de 1988 a délibérément réparti le pouvoir fiscal entre trois niveaux de gouvernement : fédéral, étatique et municipal. Les États ont obtenu l'ICMS (marchandises). Les municipalités ont obtenu l'ISS (services). Chacun des 26 États brésiliens gère sa propre réglementation de l'ICMS, créant ainsi 27 régimes fiscaux distincts (y compris le District fédéral). Mais pour la NFS-e, l'échelle est deux ordres de grandeur plus grande : 5 570 municipalités, chacune ayant l'autorité légale de fixer son propre taux d'ISS, son propre calendrier de conformité, son propre service web de validation des factures, et — crucial pour le traitement des données — sa propre mise en page documentaire.

Le résultat pratique est quelque chose qu'aucun outil d'extraction basé sur des modèles ne peut surmonter. Une facture de service émise à São Paulo place la base de cálculo ISS (base de calcul de l'ISS) à un endroit ; une facture de Campinas — une ville située à 100 kilomètres — la place à un autre. Le champ du taux d'ISS peut être étiqueté « Alíquota » dans une municipalité, « Alíquota ISS » dans une autre, et intégré dans une ligne de tableau dans une troisième. Un modèle qui fonctionne pour São Paulo échoue pour Campinas, qui échoue pour Guarulhos, qui échoue pour les 5 567 autres villes. Maintenir une bibliothèque de modèles, même pour les 20 villes où se trouvent vos fournisseurs, signifie 20 modèles qui échoueront dès la prochaine mise à jour de mise en page par une prefeitura (mairie).

Le contraste NF-e : ce à quoi ressemble une norme nationale unifiée

Le Brésil a déjà résolu ce problème de fragmentation une fois — pour les marchandises. La NF-e (Nota Fiscal Eletrônica / Facture électronique de marchandises), lancée en 2006, est régie au niveau des États par la SEFAZ (Secrétariat d'État aux Finances) selon un schéma XML national unique — version 4.0 du format. Une NF-e émise en Amazonas utilise la même structure de champs, les mêmes balises XML et les mêmes règles de validation qu'une NF-e émise au Rio Grande do Sul. Un seul modèle d'extraction fonctionne pour les 27 États. La NF-e inclut l'ICMS, le PIS, la COFINS et l'IPI — quatre impôts, chacun plus complexe que l'ISS — et pourtant, traiter un lot de documents NF-e provenant de plusieurs États est un problème d'ingénierie résolu, car la structure des données est normalisée au niveau fédéral.

Regardez maintenant la NFS-e. La structure des données est fragmentée au niveau municipal — parce que l'impôt est administré au niveau municipal — et l'impôt qu'elle porte (ISS, un taux, une ville, pas de chaîne de crédit) est le plus simple du système brésilien. C'est le paradoxe au cœur du problème de la NFS-e : plus l'impôt est simple, plus le document est fragmenté. La NF-e porte quatre impôts dans 27 États, et un seul schéma XML les gère tous. La NFS-e porte un impôt dans 5 570 villes, et il n'existe — à la mi-2026 — aucun format unique couvrant toutes les municipalités.

Quand les équipes AP disent « les factures brésiliennes sont complexes », elles parlent généralement de la NF-e — des codes fiscaux qu'elles n'ont jamais vus, des chaînes de calcul inconnues, un modèle d'autorisation nécessitant une approbation gouvernementale avant le déplacement des marchandises. Mais la NF-e est complexe de manière structurée. La NFS-e est simple de manière fragmentée — et cette dernière est plus coûteuse à traiter.

Le système NF-e a été conçu pour le destinataire : le DANFE (Document Auxiliaire de la NF-e), la version imprimable, omet la plupart des données XML, mais le XML complet est toujours accessible via le portail SEFAZ en utilisant la clé d'accès à 44 chiffres imprimée sur chaque DANFE. Le système NFS-e, en revanche, a été conçu pour l'émetteur et la municipalité. Le destinataire reçoit un PDF — le DANFSE (Document Auxiliaire de la NFS-e) — et doit se débrouiller seul pour le reste. Pas de portail unifié avec clé d'accès entre les municipalités. Aucune garantie que le PDF imprimé contienne tous les champs XML. Aucune norme nationale sur ce qui figure sur le document imprimé par rapport à ce qui reste dans la base de données municipale.

Une concurrence fiscale à ciel ouvert

Le taux d'ISS de 2 % à 5 % n'est pas un détail technique. C'est le moteur d'une concurrence fiscale entre municipalités qui aggrave la fragmentation des données. Chaque ville fixant son propre taux, les municipalités utilisent l'ISS pour attirer les entreprises. São Paulo applique un taux général de 5 %. Alphaville — un quartier d'affaires planifié à 30 km de São Paulo — facture 2 % pour la plupart des catégories de services. Une entreprise qui transfère son siège social de São Paulo à Alphaville réduit sa facture d'ISS des trois cinquièmes sans déplacer ses activités réelles.

Cette « guerre fiscale » entre municipalités a été documentée par le FMI, l'OCDE et le propre Service fédéral des impôts du Brésil comme un frein persistant à l'efficacité fiscale. Le PNUD estimait en 2023 que les recettes perdues du fait de la concurrence fiscale entre municipalités — pour l'ISS, l'IPTU et d'autres impôts locaux — pourraient atteindre plusieurs points de PIB. Mais la conséquence pour la comptabilité fournisseurs est plus immédiate : si votre prestataire informatique de São Paulo émet depuis une entité enregistrée à Alphaville, le taux d'ISS sur sa NFS-e indique 2 %, pas 5 %. Votre ERP s'attend à 5 % en fonction de l'emplacement physique du prestataire. L'écart déclenche un signal de rapprochement. Quelqu'un dans la comptabilité fournisseurs doit déterminer pourquoi le taux est erroné — ou s'il l'est vraiment.

Ce n'est pas hypothétique. Les conflits d'ISS entre la municipalité d'enregistrement du prestataire et celle du preneur de services sont si fréquents que certaines entreprises paient l'ISS deux fois — aux deux villes — plutôt que de contester le litige. Comme l'a documenté BPC Partners dans son analyse de la taxe sur les services brésilienne, l'ISS est la principale source de revenus des municipalités et le principal instrument de concurrence fiscale intercommunale. Pour une équipe de comptabilité fournisseurs traitant un lot de 50 documents NFS-e provenant de 15 villes, cela signifie que vous ne pouvez pas considérer le taux d'ISS sur la facture comme un montant fiscal vérifié prêt à être comptabilisé dans l'ERP. Vous devez le valider — par document, par ville, par code de service.

Le problème « Por Dentro » : quand un calcul d’impôt paraît simple mais ne l’est pas

Il existe une deuxième raison pour laquelle le montant de l’ISS sur une NFS-e peut piéger une validation automatisée. Au Brésil, l’ISS est calculé « por dentro » (de l’intérieur) — c’est-à-dire que la taxe est incluse dans le prix brut plutôt que d’être ajoutée par-dessus. Si la valeur nette du service est de 100 R$ et le taux d’ISS de 5 %, le montant brut n’est pas de 105 R$, mais de 100 R$ ÷ 0,95 = 105,26 R$. L’ISS est alors de 105,26 R$ × 0,05 = 5,26 R$, et non 5,00 R$.

Pour un seul document, la différence est de 0,26 R$ — négligeable. Pour 50 documents par mois sur 12 mois, avec des taux d’ISS variant entre 2 % et 5 %, et des valeurs de service allant de 5 000 R$ à 250 000 R$, l’écart cumulé entre un calcul naïf « taux × net » et le montant réel d’ISS « por dentro » peut franchir des seuils significatifs. Plus important encore, si votre flux d’extraction ou votre ERP est configuré pour valider l’ISS en multipliant le taux par la base sans tenir compte du calcul por dentro, chaque document semblera contenir une erreur — et votre équipe passera des heures à enquêter sur des erreurs qui n’en sont pas, mais simplement un décalage entre la logique d’extraction et la convention de calcul de la taxe.

La méthode por dentro s’applique à l’ICMS et à l’ISS dans tout le Brésil, et elle est bien documentée — elle est décrite dans le Résumé fiscal mondial PwC pour le Brésil et dans le texte officiel de la LC 116/2003. Mais la plupart des équipes AP internationales ne rencontrent pas la taxation « por dentro » dans leurs opérations nationales. Une facture américaine ou européenne ajoute la taxe par-dessus ; une facture brésilienne l’incorpore. Sans ce contexte, le montant d’ISS sur une NFS-e reçue ressemble à une erreur de calcul. Ce n’en est pas une. C’est une convention arithmétique différente appliquée à une taxe dont le taux a été fixé par une ville dont la mise en page est différente de celle de la ville précédente.

Le paradoxe de la réforme fiscale de 2026 : un remède qui aggrave d'abord les symptômes

La réforme de la taxe sur la consommation au Brésil — la plus vaste depuis des décennies — est censée résoudre ce problème. En vertu de l'amendement constitutionnel 132/2023, réglementé par la loi complémentaire 214/2025, cinq impôts existants (PIS, COFINS, ICMS, ISS, IPI) seront progressivement remplacés par deux : la CBS (Contribuição sobre Bens e Serviços / Contribution sur les biens et services) au niveau fédéral et l'IBS (Imposto sobre Bens e Serviços / Taxe sur les biens et services) au niveau des États et des municipalités. Le taux standard combiné CBS + IBS est estimé à environ 26,5 %. À long terme — d'ici 2033 — cela unifiera l'assiette de la taxe sur la consommation, éliminera la fragmentation municipale de l'ISS et, en principe, normalisera les formats de factures de services à l'échelle nationale.

Le problème, c'est le calendrier de transition. Voici à quoi ressemblent les années entre aujourd'hui et 2033 pour le traitement des données AP :

Pour le traitement des données AP, cette transition est un multiplicateur de complexité. Entre 2026 et 2033, une seule facture de service peut comporter simultanément des champs ISS, CBS et IBS — chacun avec son propre taux, assiette et montant, chacun mis à jour selon un calendrier différent selon la municipalité. La préfecture de São Paulo a publié la version 3.2 du format NFS-e en août 2025 pour introduire les champs IBS/CBS ; d'autres villes suivront selon leurs propres calendriers. Une NFS-e reçue en 2028 d'une ville peut être structurellement différente d'une NFS-e reçue le même mois d'une autre ville — non pas à cause de l'ancien problème de fragmentation, mais à cause du nouveau qui s'y superpose.

La réforme finira par résoudre la fragmentation. Mais d'ici là, elle l'aggravera temporairement — car la transition elle-même est fragmentée. Chaque ville met à jour son système à son rythme. L'adhésion de chaque ville à la norme nationale NFS-e est volontaire. Le calendrier d'introduction des champs IBS varie d'une ville à l'autre. Sept ans de complexité croissante avant la simplification finale.

Le correctif partiel du SNNFS-e : 2 000 municipalités dedans, 3 570 encore dehors

Le Brésil construit une norme nationale NFS-e — le SNNFS-e (Sistema Nacional da NFS-e) — depuis 2023. Ce système propose un format XML unifié, un portail de facturation centralisé, un référentiel national de données (ADN — Ambiente de Dados Nacional) et un document unique de paiement fiscal (DNA — Documento Nacional de Arrecadação) valable dans toutes les municipalités participantes. En janvier 2026, environ 2 000 municipalités avaient activé le système — soit environ 35 % des villes brésiliennes — couvrant environ 80 % des contribuables en volume, car les premiers adoptants sont majoritairement les grandes municipalités à fort volume.

Mais voici ce que cachent les chiffres d'adoption. São Paulo, la plus grande ville du Brésil et le moteur économique du pays, a confirmé qu'elle ne migrera pas vers le système national NFS-e en 2026. La ville conservera sa propre plateforme NFS-e — la Nota Fiscal Paulistana — qui fonctionne avec son propre schéma XML, son propre service web, son propre manuel de mise en page (version 3.2 en août 2025) et son propre calendrier de mise à jour. São Paulo n'est pas seule. D'autres grandes villes évaluent leurs options, et la loi n'impose pas la migration — elle l'encourage par la menace de perdre les transferts fédéraux, mais les grandes villes disposant d'une base de recettes propres substantielle sont moins sensibles à cette menace.

Le résultat est un système à deux vitesses indéfini : certaines villes sur la norme nationale, d'autres sur leurs propres plateformes municipales, toutes tenues de transmettre les données au référentiel national ADN — ce qui garantit la visibilité fiscale mais ne standardise en rien le format du document qui atterrit dans votre boîte de réception AP. Le destinataire reçoit toujours des mises en page diverses. Le problème de fragmentation persiste.

Et pour les 106 petites municipalités qui n'avaient toujours pas signé l'accord début 2026, selon le Service fédéral des recettes du Brésil, les prestataires de services de ces villes peuvent encore émettre des NFS-e via des systèmes hérités — ou, dans certains cas, via des processus papier antérieurs à la facturation numérique. La Receita Federal elle-même a reconnu le 6 janvier 2026 que de nombreuses municipalités avaient signé l'accord à la dernière minute mais n'avaient pas achevé la configuration technique nécessaire à leur mise en service.

Ce que cela signifie pour votre flux de travail AP

Si votre entreprise traite 30 à 50 factures de services par mois provenant de prestataires brésiliens dans 10 villes différentes, vous n'êtes pas confronté à un problème de saisie de données. Vous êtes confronté à un problème structurel de fragmentation des données créé par le fédéralisme fiscal brésilien, amplifié par la concurrence fiscale entre municipalités, compliqué par une convention de calcul fiscal non standard, et qui entre maintenant dans une transition de sept ans durant laquelle chaque document portera deux cadres fiscaux parallèles.

La réponse AP standard à la diversité des documents — créer plus de modèles — échoue ici. Vous ne pouvez pas résoudre par des modèles les 5 570 mises en page potentielles. Même si vous ne traitez qu'avec 10 villes, celles-ci peuvent chacune mettre à jour indépendamment la mise en page de leur NFS-e, selon des calendriers que vous ne contrôlez pas. La préfecture de São Paulo a publié trois versions du manuel NFS-e rien qu'en 2025. Un modèle de maintenance de modèles qui fonctionnait pour 27 schémas de NF-e au niveau des États s'effondre à l'échelle municipale.

La réponse AP standard à la complexité fiscale — faire confiance à la facture — échoue également ici. Le taux d'ISS sur une NFS-e d'Alphaville peut indiquer 2 % alors que votre ERP attend 5 % en fonction de l'emplacement physique du prestataire à São Paulo. Le prestataire peut avoir un enregistrement légitime à Alphaville, ou il peut pratiquer une optimisation fiscale que votre équipe de conformité doit examiner. Le montant de l'ISS peut sembler erroné car il a été calculé por dentro alors que votre logique de validation s'attendait à une arithmétique additive. Faire confiance à la facture sans vérification signifie importer des erreurs fiscales potentielles dans votre ERP — une exposition à la conformité qui s'aggrave avec chaque document.

Avant de penser aux outils ou à l'automatisation, vous devez reconnaître ce que vous traitez : un format de document qui a été légalement conçu pour ne pas converger vers une norme, émis par un système fiscal fragmenté au niveau municipal par conception constitutionnelle, pendant une période de réforme qui aggravera temporairement la fragmentation.

Voici le diagnostic. La solution n'est pas un meilleur modèle. C'est une approche d'extraction qui ne dépend pas du tout de modèles — une approche qui lit les champs par leur signification (CNPJ = identifiant fiscal à 14 chiffres étiqueté « Prestador ») plutôt que par leur position sur la page d'une ville spécifique. L'extraction sémantique — alimentée par des modèles de langage visuels qui comprennent la structure des documents comme une personne les lit — est la réponse technique à un problème juridictionnel que les outils basés sur des modèles n'ont jamais été conçus pour gérer. Mais la première étape consiste à comprendre la nature du problème. Sans cela, vous évaluez les outils selon de mauvais critères.

FAQ : Variation municipale de la NFS-e brésilienne et traitement AP

Pourquoi les formats de NFS-e diffèrent-ils d'une ville brésilienne à l'autre ?

Parce que l'ISS est un impôt municipal, et non fédéral. La Constitution fédérale de 1988 accorde à chacune des 5 570 municipalités brésiliennes le pouvoir de légiférer et d'administrer sa propre taxe sur les services. La LC 116/2003 a fourni des directives nationales (taux de 2 % à 5 %, 40 catégories de services) mais a explicitement laissé la mise en œuvre — y compris le format de la facture électronique — à chaque municipalité. Contrairement à la NF-e (facture de marchandises), qui est régie par une norme XML fédérale unique dans tous les États, la standardisation du format de la NFS-e dépend de l'adoption volontaire par les municipalités du système national SNNFS-e. Début 2026, environ 2 000 municipalités l'avaient adopté ; São Paulo et d'autres grandes villes ont jusqu'à présent choisi de conserver leurs propres systèmes.

Comment la réforme fiscale de 2026 affecte-t-elle le traitement des NFS-e ?

La réforme introduit l'IBS et la CBS pour éventuellement remplacer l'ISS et d'autres taxes sur la consommation, mais la transition s'étend jusqu'en 2033. Pendant cette période, les documents NFS-e comporteront à la fois d'anciens champs ISS et de nouveaux champs IBS/CBS — créant une double ventilation fiscale sur un seul document. Chaque municipalité met à jour son format selon son propre calendrier, ce qui signifie que vous pouvez recevoir des documents NFS-e de différentes villes avec différentes combinaisons de champs fiscaux pendant les années de transition. La réforme simplifie le tableau à long terme (une TVA unifiée d'ici 2033) mais augmente la complexité du traitement à court terme.

Puis-je créer des modèles pour les villes où se trouvent mes fournisseurs ?

Oui, mais le coût de maintenance est le problème. Même si vous ne traitez que des NFS-e de 10 villes, celles-ci peuvent chacune mettre à jour leur format indépendamment — São Paulo a publié trois versions manuelles rien qu'en 2025. Un modèle qui fonctionne en janvier peut ne plus fonctionner en août parce que la préfecture a modifié les positions des champs. À l'échelle municipale — 10 villes × plusieurs versions de format × des calendriers de mise à jour indépendants — la maintenance des modèles devient un coût opérationnel récurrent, et non une configuration unique. Pour une discussion sur la façon dont l'extraction sémantique sans modèle gère cela, consultez notre guide sur l'extraction de données NFS-e pour les opérations brésiliennes.

Pourquoi le montant de l'ISS sur ma NFS-e ne correspond-il pas à taux × base ?

L'ISS au Brésil est calculé « par l'intérieur » — la taxe est incluse dans le prix brut plutôt que d'être ajoutée. Un service net de 100 R$ à 5 % d'ISS donne un brut de 100 R$ ÷ 0,95 = 105,26 R$, et non 105 R$. L'ISS est alors de 5,26 R$, et non de 5,00 R$. Si votre logique de validation multiplie le taux par la base sans tenir compte de cette convention, chaque document semblera comporter une erreur de calcul. La formule est : ISS = (valeur brute du service × taux), où brut = valeur nette du service ÷ (1 − taux).

Est-il sûr d'importer les montants d'ISS des NFS-e directement dans mon ERP sans validation ?

Pas vraiment, pour deux raisons. Premièrement, les municipalités brésiliennes se font concurrence sur les taux d'ISS — un prestataire enregistré à Alphaville (2 %) peut émettre depuis un lieu que vous connaissez comme São Paulo (5 %), créant un écart de taux légitime mais inattendu. Deuxièmement, le champ « ISS Retido na Fonte » (retenu à la source) sur une NFS-e transfère l'obligation de paiement de la taxe du prestataire à votre entreprise — s'il est marqué « Sim », c'est vous qui devez payer l'ISS à la municipalité, et non simplement comptabiliser la facture. Ignorer ce drapeau est un risque de non-conformité, pas seulement une erreur de données.

Pourquoi la NFS-e est-elle plus difficile à automatiser que la NF-e alors que l'ISS est plus simple que l'ICMS ?

Parce que la normalisation suit la juridiction. L'ICMS est un impôt d'État, régi par 27 autorités SEFAZ qui se sont mises d'accord sur un seul format XML (layout NF-e 4.0) avant la mise en service du système en 2006. L'ISS est un impôt municipal, régi par 5 570 préfectures qui ne se sont jamais accordées sur un seul format — et le gouvernement fédéral n'a commencé à pousser à la normalisation via le SNNFS-e qu'en 2023, 17 ans après la normalisation de la NF-e. La taxe est plus simple, mais la structure de gouvernance qui crée le document est plus fragmentée — et la gouvernance détermine le format.

Diagnostic avant prescription

Le problème du traitement des NFS-e n'est pas que la saisie des données est lente. C'est que vos documents d'entrée sont structurellement non convergents — une caractéristique du fédéralisme fiscal brésilien, pas une lacune d'intégration temporaire. Tant que vous n'aurez pas posé le diagnostic, chaque évaluation d'outil se fera par rapport à un mauvais référentiel. Vous ne cherchez pas quelque chose qui accélère la frappe. Vous cherchez quelque chose qui supprime la dépendance à l'uniformité des mises en page, car dans un système de 5 570 formats de documents municipaux, l'uniformité des mises en page n'existe pas.

C'est pourquoi l'extraction sémantique — qui localise les champs par leur sens plutôt que par leur position — correspond au problème d'une manière que l'OCR basé sur des modèles ne peut pas. Pour une démonstration pratique de son fonctionnement sur des NFS-e individuelles, y compris les codes de service LC 116, les drapeaux de retenue d'ISS et l'extraction de champs entre villes, voir comment extraire les données des NFS-e pour les opérations brésiliennes. Pour le scénario de volume — traiter 50 NFS-e ou plus de plusieurs villes en un seul lot — voir traitement par lots de NFS-e multi-municipalités.

Le diagnostic structurel ne prescrit pas un outil. Il définit le problème qu'un outil doit résoudre. L'écart entre la compréhension de la fragmentation et sa résolution avec la bonne approche d'extraction est la différence entre réagir à chaque changement de mise en page d'une ville et traiter la NFS-e de n'importe quelle ville sans remarquer de laquelle elle vient.