Intégration logiciel ESG SI : API et connecteurs

Les trois modes d'intégration au SI et leurs implications

Mode 1 : Les connecteurs natifs pré-packagés

Un connecteur natif est une intégration pré-développée par l'éditeur avec un système tiers spécifique : SAP, Oracle, Microsoft Dynamics, Workday, Cegid, ADP, Sage, et d'autres selon les éditeurs. Il s'active via une configuration, sans développement spécifique. Les flux de données remontent automatiquement selon une fréquence paramétrable.

Avantage principal : la mise en œuvre se compte en jours à semaines, le coût est maîtrisé (inclus dans la licence ou forfait modique), et la maintenance est assurée par l'éditeur en cas d'évolution du système tiers.

Limite : le connecteur n'existe que pour les couples éditeur/système tiers les plus courants. Si votre SIRH n'est pas dans la liste, le connecteur natif ne vous concerne pas.

Si votre SI repose sur des systèmes standard, les connecteurs natifs représentent la voie la plus rapide et la plus économique. La première question à poser à chaque éditeur est la liste précise de ses connecteurs disponibles.

Mode 2 : L'API standard REST ou GraphQL

Une API (Application Programming Interface) est une interface technique qui permet à un système tiers de communiquer avec le logiciel ESG selon un protocole standardisé. REST (Representational State Transfer) est le protocole le plus répandu dans les architectures modernes. GraphQL, plus récent, offre une plus grande flexibilité dans les requêtes de données.

Fonctionnement : la DSI interne ou un intégrateur externe développe la connexion entre le SI et le logiciel ESG en utilisant l'API mise à disposition par l'éditeur.

Avantage : couverture universelle, flexibilité maximale, indépendance vis-à-vis de la liste des connecteurs natifs.

Limite : l'API implique un développement (dix à quarante jours-homme selon la complexité) qui doit être maintenu dans le temps à chaque évolution du SI.

L'API standard est la solution universelle. Elle a un coût de développement et de maintenance à intégrer dans le TCO (Total Cost of Ownership).

Mode 3 : Les intégrations sur mesure et les échanges de fichiers

Pour les systèmes historiques ou les applications propriétaires, les options techniques sont plus artisanales : échanges de fichiers (CSV, Excel, XML) via SFTP (Secure File Transfer Protocol) ou dépôt cloud, ETL (Extract, Transform, Load) qui construit un pont entre systèmes hétérogènes, développements ad hoc négociés avec l'éditeur ou un intégrateur tiers.

Ces intégrations offrent une flexibilité totale mais au prix d'un coût élevé, d'une dépendance forte à la maintenance manuelle et d'un risque de dette technique. Les multiplier alourdit le TCO et fragilise le projet dans la durée. Elles doivent rester l'exception.

Tableau comparatif des différents modes d'intégration

Connaître le mode d'intégration prévu pour chaque système tiers est un préalable au chiffrage TCO et au cadrage du calendrier projet.

La grille technique à passer en consultation avec l'éditeur

Questions sur les connecteurs natifs disponibles

Ces questions révèlent la maturité réelle du catalogue d'intégration de l'éditeur.

• Quelle est votre liste complète de connecteurs natifs, avec les systèmes couverts (ERP, SIRH, comptabilité, achats, BI) ?
• Ces connecteurs sont-ils inclus dans la licence ou facturés séparément ?
• Quels sont les délais de mise en œuvre typiques par connecteur ?
• Quels flux de données sont couverts nativement : achats, énergie, effectifs, déplacements, données financières ?
• À quelle fréquence les données remontent-elles : temps réel, journalier, hebdomadaire, mensuel ?

Demander la liste précise des connecteurs et les vérifier sur votre propre écosystème SI, pas sur des noms génériques. La liste marketing et la liste technique ne sont pas toujours identiques.

Questions sur l'API et son niveau de maturité

La qualité de l'API est un indicateur direct de la maturité technique de l'éditeur.

• Quelle est la documentation de votre API : Swagger, Postman, portail développeur dédié ?
• Cette documentation est-elle publique et accessible avant le déploiement ?
• Quel protocole utilise-t-elle : REST, GraphQL, ou SOAP (Simple Object Access Protocol, plus ancien) ?
• Quels endpoints sont disponibles : lecture seule, lecture-écriture, quels périmètres fonctionnels ?
• Quel est le rate limit (nombre d'appels autorisés par minute) ? Peut-il être négocié pour des usages intensifs ?
• Quelle authentification est supportée : OAuth 2.0, clé API statique, JWT (JSON Web Token) ?

Une API sans documentation publique et sans exemples de code est une API artisanale. Un éditeur techniquement mature propose un portail développeur avec documentation, environnement sandbox et exemples d'intégration opérationnels.

Questions sur les formats de données et la sémantique

L'intégration technique ne suffit pas si les données ne se comprennent pas d'un système à l'autre.

• Quels formats de données sont acceptés en import natif : CSV, JSON, XML, Excel structuré ?
• Comment le logiciel gère-t-il les référentiels de données internes (facteurs d'émission, unités de mesure, devises, codes analytiques) ?
• Comment sont gérées les mises à jour de référentiels dans le temps : révision des facteurs d'émission, changement de méthodologie, évolution des ESRS (European Sustainability Reporting Standards) ?
• Le logiciel garantit-il la traçabilité de chaque donnée : source, date de collecte, contributeur, méthode de calcul ?

Une intégration technique aboutie ne vaut rien si les référentiels de données ne sont pas alignés entre le SI source et le logiciel ESG. La question sémantique est aussi importante que la question protocolaire.

Questions sur l'authentification et le SSO

La couche authentification est souvent traitée en dernier, alors qu'elle conditionne l'acceptabilité du projet en revue d'architecture DSI.

• Le logiciel supporte-t-il le SSO (Single Sign-On) avec votre annuaire d'entreprise : Azure AD, Okta, ADFS ?
• Quels protocoles d'authentification sont supportés : SAML 2.0 (Security Assertion Markup Language), OAuth 2.0, OpenID Connect ?
• Comment sont gérés les provisionnements et déprovisionnements d'utilisateurs : via SCIM (System for Cross-domain Identity Management) ou synchronisation annuaire manuelle ?
• Le logiciel supporte-t-il l'authentification multifacteur (MFA) ?

Pour sécuriser l'accès aux données ESG au-delà de l'authentification, rendez-vous sur l’article dédié qui traite la sécurité dans sa globalité. Un logiciel sans SSO enterprise-grade se heurtera à la DSI en revue d'architecture. Cette question se pose tôt dans la consultation, pas après la signature.

Questions sur la gestion des erreurs et la supervision

La robustesse d'une intégration se révèle dans la façon dont elle gère les incidents, pas dans son comportement nominal.

• Comment le logiciel gère-t-il les erreurs de synchronisation : retry automatique, alertes, journalisation des erreurs ?
• Quel niveau de supervision est proposé : tableau de bord des flux, alertes en cas d'anomalie, accès aux logs ?
• Comment sont gérés les blocages temporaires du système tiers : rate limiting côté source, maintenances planifiées, incidents ?
• Quel SLA (Service Level Agreement) est proposé sur les intégrations natives en termes de disponibilité et de temps de rétablissement ?

Grille récapitulative des questions techniques à poser en consultation

‍

Les pièges classiques et comment les éviter

Piège 1 - Sous-estimer la charge DSI interne

Le piège le plus fréquent est de considérer que l'éditeur prend tout en charge. Même avec des connecteurs natifs, la DSI interne reste mobilisée sur plusieurs postes : ouverture des accès techniques et gestion de la sécurité réseau, configuration des mappings de données entre référentiels internes et logiciel ESG, maintenance lors des évolutions du SI (mise à jour d'ERP, migration cloud, changement de SIRH).

Cette charge se chiffre en jours-homme et doit figurer dans le TCO du projet. Pour intégrer correctement la charge DSI interne dans le TCO du projet, rendez-vous sur l’article qui détaille cette méthode de chiffrage.

Piège 2 - Ne pas tester les connecteurs sur vos propres données

Les connecteurs fonctionnent toujours en démo, sur des données soigneusement préparées par l'éditeur. Sur vos données réelles, les surprises sont fréquentes : formats non standards que le connecteur ne sait pas ingérer, volumes trop importants qui saturent l'API, historique de données incompatible avec le modèle du logiciel, codes analytiques ou référentiels internes non reconnus.

La seule façon de valider un connecteur est de le tester sur un échantillon de données réelles en POC. Pour tester les connecteurs en POC sur vos données RSE réelles, un article dédié structure cette phase. Un connecteur non testé sur données réelles est un connecteur dont la fiabilité reste inconnue.

Piège 3 - Oublier la gestion du changement dans le SI

Le SI évolue en continu : mises à jour d'ERP, migrations cloud, changements de SIRH, réorganisations des référentiels comptables. Chaque évolution peut casser les intégrations existantes, parfois silencieusement.

Questions à poser avant la signature : quel est l'engagement de l'éditeur pour maintenir les connecteurs en cas d'évolution du système tiers ? Quel préavis est communiqué en cas de changement d'API ? Ces engagements doivent être contractualisés, pas seulement promis verbalement en démo. Un logiciel ESG s'inscrit dans un SI vivant, et la durabilité de l'intégration est un critère de valeur à long terme.

Piège 4 - Ne pas anticiper la traçabilité pour l'audit CSRD

Pour la CSRD notamment, l'auditeur doit pouvoir remonter d'un chiffre agrégé dans le rapport jusqu'à la donnée source dans le SI d'origine. Cette capacité de drill-through (navigation de l'agrégé vers la source) dépasse l'intégration technique standard : elle nécessite une traçabilité complète du parcours de la donnée, depuis l'ERP jusqu'au chiffre publié.

Question à poser explicitement : comment garantissez-vous la traçabilité de chaque donnée, du SI source jusqu'au rapport CSRD, avec l'historique complet des modifications ? Un logiciel qui intègre bien les données mais ne garantit pas leur traçabilité complète fragilise le rapport face à l'auditeur.

Conclusion

Un logiciel ESG s'intègre à son SI selon trois modes aux implications très différentes :

• Les connecteurs natifs (rapides et économiques pour les systèmes standard),
• L'API standard REST ou GraphQL (flexible mais à développer et maintenir),
• Les intégrations sur mesure (à réserver aux cas exceptionnels)

Identifier le mode d'intégration prévu pour chaque système tiers est un préalable au chiffrage TCO et au cadrage du calendrier.

Une grille de questions en cinq thématiques permet d'évaluer techniquement chaque éditeur en consultation et d'écarter les solutions immatures avant la shortlist.

Les quatre pièges classiques (charge DSI sous-estimée, connecteurs non testés, gestion du changement SI ignorée, traçabilité pour l'audit non anticipée) se détectent en consultation. Un POC sur données réelles reste la seule façon de valider l'intégration dans les conditions réelles du projet.