--- title: "XBRL : bien plus qu'une simple conformité" date: "2009-07-13" categories: - "xbrl" tags: - "altova" - "data-mapping" - "mapforce" - "xbrl" description: Découvrez comment XBRL va au-delà de la simple conformité pour améliorer l'efficacité de la gestion des données. Explorez les solutions de conversion intégrées avec Altova MapForce pour une production de rapports simplifiée. --- Status: #blog Tags: #altova #data-mapping #mapforce #xbrl Categories: [xbrl](/blog/fr/category/xbrl.md) # XBRL : bien plus qu'une simple conformité Récemment revenu d'une courte visite à la [19e Conférence internationale XBRL](http://conference.xbrl.org/) à Paris, je ne peux m'empêcher de penser que de nombreuses organisations ne comprennent tout simplement pas l'intérêt de cette technologie, et que la réglementation de la SEC pourrait en être en partie responsable. On pourrait penser (en tout cas, c'est ce que je pensais) qu'un an après l'introduction des exigences de reporting XBRL par la plus grande économie mondiale, cette conférence serait bondée de représentants d'entreprises désireux d'en savoir plus sur la manière, et surtout, _sur les raisons_ pour lesquelles ils devraient utiliser XBRL pour structurer leurs données financières. Mais hélas, ce n'était pas le cas. Je ne peux qu'émettre l'hypothèse que le faible nombre de participants, en particulier en provenance des États-Unis, est dû au fait que les organisations considèrent encore XBRL principalement comme une question de conformité et continuent de confier la "balisage" de leurs états financiers à des entreprises spécialisées dans l'impression financière ou à d'autres entités chargées du dépôt auprès de l'EDGAR. Alors, XBRL est-il une question de conformité ? Bien sûr que oui, mais c'est bien plus que cela. Je peux vous le dire avec certitude, car je travaille chez Altova et nous ne nous concentrons pas uniquement sur les logiciels de conformité. Nous développons des outils qui aident les entreprises à optimiser l'efficacité de leurs _interne_ Ces processus visent à réduire le temps et les coûts globaux du flux de travail de gestion des données. Et cela est tout à fait réalisable pour toute entreprise utilisant XBRL, mais cela implique d'examiner de manière proactive la façon dont vous gérez vos données. "L'étiquetage" implique que les états financiers sont établis de manière traditionnelle, dans un tableur ou un logiciel de comptabilité, puis qu'ils sont ensuite modifiés de manière rétroactive et méticuleuse en y ajoutant des étiquettes XBRL pour les rendre conformes. Beurk... pas étonnant que la conformité ait une si mauvaise réputation ! N'avons-nous pas déjà assez de travail à faire ? Et attendez, n'est-ce pas simplement ajouter une tâche manuelle à une autre, ce qui double les risques d'erreur humaine ? Je ne sais pas exactement quand ce terme "étiquetage" est devenu si populaire pour décrire la mise en œuvre de XBRL, mais il a surtout réussi à simplifier à l'excès quelque chose qui n'était pas très compliqué au départ (il est vrai, ce terme a probablement été inventé par quelqu'un du service marketing, dont je fais partie). Quoi qu'il en soit, mettons de côté cette idée d'étiquetage et voyons si nous pouvons trouver quelque chose de plus audacieux. Imaginons que toutes les données financières de votre entreprise soient stockées dans un système centralisé, comme une base de données, un système de comptabilité/ERP, des fichiers XML, ou même une combinaison de ces éléments. Et si vous pouviez simplement [convertir vos données au format XBRL en interne](https://www.altova.com/fr/products/mapforce/xbrl_mapping.html) au lieu de faire appel à des consultants externes qui analyseraient les rapports et étiqueteraient chaque élément ? Et si vous pouviez même réutiliser cette conversion la prochaine fois que vous devriez produire un rapport financier similaire ? Et si votre service informatique pouvait même [automatiser vos processus de déclaration XBRL](https://www.altova.com/fr/products/mapforce/xbrl_mapping.html) ? **[Correspondances XBRL](https://www.altova.com/fr/products/mapforce/xbrl_mapping.html)** Altova MapForce est une solution de niveau entreprise [outil d'intégration de données](https://www.altova.com/fr/products/mapforce/data_mapping.html) qui vous permet de faire exactement cela. Il est utilisé par les développeurs et les architectes d'applications, mais son interface graphique intuitive rend MapForce accessible à toute personne ayant une compréhension des données à mapper. Examinons un exemple partiel pour illustrer à quel point cela peut être simple : la première étape consiste à charger le composant de données source, dans ce cas une base de données, dans la zone de conception de MapForce. [![xbrl1](https://www.altova.com/blog/images/XBRLsomuchmorethancompliance_E946/xbrl1_thumb.jpg "xbrl1")](https://www.altova.com/blog/images/XBRLsomuchmorethancompliance_E946/xbrl1.jpg) Notez que le composant de mappage est une représentation des tables et des colonnes de la base de données. Par conséquent, les données sous-jacentes peuvent changer à tout moment, et le mappage lui-même ne sera pas affecté. Il en va de même pour toute structure de mappage que vous utilisez dans MapForce, qu'il s'agisse de fichiers XML, de bases de données, de fichiers plats, de formats EDI, de fichiers Excel, de XBRL ou de services web. Ensuite, nous ajouterons notre composant de mappage cible, qui, dans ce cas, est une taxonomie d'extension XBRL de base, construite sur la base de [les normes comptables américaines (US GAAP) pour les entreprises commerciales et industrielles](http://xbrl.us/taxonomies/Pages/default.aspx). [![xbrl2](https://www.altova.com/blog/images/XBRLsomuchmorethancompliance_E946/xbrl2_thumb.jpg "xbrl2")](https://www.altova.com/blog/images/XBRLsomuchmorethancompliance_E946/xbrl2.jpg) Maintenant, nous pouvons commencer la cartographie en reliant des lignes pour associer des éléments. Il y aura des cas où nous devrons appliquer des [règles de traitement des données](https://www.altova.com/fr/features_datafilters_mapforce.html) pour modifier légèrement le format, filtrer les données, ou même ajouter des constantes pour répondre aux exigences de reporting XBRL qui n'existent pas dans la base de données. Tout cela peut être très facilement réalisé en faisant glisser et déposer des fonctions intermédiaires depuis la bibliothèque MapForce, située dans la barre latérale. Supposons, par exemple, que votre base de données exige automatiquement un format de date et heure pour enregistrer toute période comptable. Comme les rapports XBRL n'exigent que la date, nous devons supprimer l'information relative à l'heure dans notre processus de conversion. Pour cela, faites simplement glisser une fonction de conversion de date et heure vers date depuis la bibliothèque et reliez les lignes entre votre base de données et le composant XBRL. [![xbrl4](https://www.altova.com/blog/images/XBRLsomuchmorethancompliance_E946/xbrl4_thumb.jpg "xbrl4")](https://www.altova.com/blog/images/XBRLsomuchmorethancompliance_E946/xbrl4.jpg) Bien sûr, vous devrez probablement également ajouter une variété d'autres fonctions mathématiques, logiques ou d'autres types à vos données, et vous trouverez une longue liste de ces fonctions déjà disponibles dans la bibliothèque de fonctions. Vous pouvez également ajouter facilement des fonctions personnalisées, si nécessaire, à l'aide d'un outil de création de fonctions graphique. Finalement, votre mappage ressemblera à ceci : [![xbrl6](https://www.altova.com/blog/images/XBRLsomuchmorethancompliance_E946/xbrl6_thumb.jpg "xbrl6")](https://www.altova.com/blog/images/XBRLsomuchmorethancompliance_E946/xbrl6.jpg) Maintenant, cliquez simplement sur l'onglet "Sortie" pour voir à quoi ressemble le format XBRL. Et voilà... une structure de données réutilisable et extensible que vous pouvez utiliser chaque fois que vous devez soumettre des données au format XBRL. Vous pouvez même intégrer l'interface de mappage dans une autre application, ou demander au service informatique de générer un code qui automatisera la création des fichiers XBRL chaque fois qu'un rapport doit être soumis. Pour une vue d'ensemble plus détaillée du fonctionnement du [mappage XBRL](https://www.altova.com/fr/products/mapforce/xbrl_mapping.html) dans MapForce, consultez notre tutoriel Altova sur le [XBRL](https://www.altova.com/fr/aot/online-training.aspx). Voici donc un exemple très simple de la génération directe de données XBRL à partir d'un système comptable : il n'est pas nécessaire de ressaisir les informations, de créer un ensemble de rapports financiers traditionnels, et encore moins de procéder à un "étiquetage". Et le plus important, tout cela peut être facilement réalisé en interne et à une fraction du coût. Maintenant, ne me faites pas de malentendu, l'externalisation pourrait tout à fait avoir sa place dans la mise en œuvre du XBRL au sein de votre entreprise. [Création d'une taxonomie d'extension XBRL](https://www.altova.com/fr/xbrl-taxonomy-editor.html), Par exemple, il est possible que vous préfériez confier cette tâche à des personnes ayant des années d'expérience dans l'utilisation de la syntaxe XBRL et d'autres aspects complexes. Mais la conversion des données financières de votre organisation au format XBRL... ne devrait-elle pas être confiée à ceux qui connaissent le mieux ces données ? Pour plus d'informations sur les outils Altova MissionKit [pour XBRL](https://www.altova.com/fr/solutions/xbrl-tools.html) – qui incluent le support pour [la création de correspondances et l'automatisation de XBRL](https://www.altova.com/fr/products/mapforce/xbrl_mapping.html), [la validation de XBRL et la création de taxinomies](https://www.altova.com/fr/xbrl.html), et [l'affichage de XBRL](https://www.altova.com/fr/features_xbrl_rendering.html) – veuillez consulter le site [https://www.altova.com/solutions/xbrl-tools.html](https://www.altova.com/fr/solutions/xbrl-tools.html)… ou [téléchargez dès aujourd'hui le logiciel Altova MissionKit](https://www.altova.com/fr/download/missionkit/software_development_tools_enterprise.html) !