netsuite-articles
broad-erp-tech-fr
Résumez l'article avec votre IA :
Les Web Services SOAP de NetSuite vont disparaître. Mais la première étape ne consiste pas à reconstruire toutes vos intégrations avec REST.
Il faut d'abord comprendre quelles intégrations utilisent encore SOAP, quels processus métier en dépendent, qui en est responsable et quelles options de migration doivent être évaluées.
Oracle NetSuite a confirmé que l'endpoint SOAP 2025.2 sera le dernier prévu et que les Web Services SOAP seront supprimés avec la version NetSuite 2028.2. Les intégrations utilisant encore SOAP cesseront alors de fonctionner. Consultez la documentation Oracle sur les versions WSDL.
Pour les entreprises européennes qui utilisent NetSuite dans plusieurs entités, pays et applications, la migration SOAP représente donc bien plus qu'un simple projet API. Une connexion peut prendre en charge des processus de facturation, de traitement des commandes, de CRM, de gestion bancaire, de fiscalité ou de reporting.
La première priorité est donc d'obtenir une visibilité claire sur les intégrations existantes.
Oracle abandonne progressivement SuiteTalk SOAP Web Services au profit de SuiteTalk REST Web Services.
Oracle recommande désormais d'utiliser REST Web Services avec OAuth 2.0 pour toutes les nouvelles intégrations, comme indiqué dans sa documentation officielle sur les versions WSDL.
La transition peut être résumée ainsi :
.webp)
Il est important de distinguer trois situations : un endpoint pris en charge, un endpoint encore disponible mais non pris en charge et un endpoint définitivement supprimé.
Un endpoint pris en charge peut encore bénéficier de correctifs de la part d'Oracle. Un endpoint non pris en charge peut rester techniquement accessible, mais ne bénéficie plus du support d'Oracle. Un endpoint supprimé est désactivé et ne peut plus être utilisé.
La FAQ d'Oracle sur la suppression de SOAP détaille cette évolution version par version.
Il existe toutefois une légère différence de calendrier dans la documentation Oracle : plusieurs pages consacrées aux WSDL indiquent que seul l'endpoint 2025.2 sera pris en charge à partir de la version 2027.1, tandis que la FAQ sur la suppression de SOAP mentionne la version 2027.2.
Les entreprises doivent donc vérifier le statut de leurs endpoints dans la documentation Oracle la plus récente lors de la planification de leur migration.
Il est également important de préciser que 2028.2 désigne une version de NetSuite, et non une date calendaire fixe. Le calendrier réel dépend du déploiement des versions Oracle sur chaque compte.
Oracle fait de REST Web Services et d'OAuth 2.0 les technologies de référence pour les intégrations NetSuite.
SuiteTalk REST Web Services est la solution destinée à remplacer SOAP. Oracle recommande aux entreprises qui utilisent des intégrations SOAP personnalisées de commencer à planifier leur migration vers REST.
Lorsqu'un besoin spécifique ne peut pas être couvert directement par REST Web Services, un RESTlet développé avec SuiteScript peut constituer une alternative.
C'est pourquoi la migration SOAP vers REST ne doit pas être considérée comme un simple remplacement d'endpoint. Chaque intégration doit être analysée en fonction du processus métier qu'elle prend en charge.
Un audit de préparation à la fin de SOAP doit répondre à une question simple :
Quelle place occupe SOAP dans notre architecture NetSuite et que se passerait-il si chaque connexion cessait de fonctionner ?
Pour y répondre, il ne suffit pas de compter les intégrations existantes.
Commencez par établir un inventaire des intégrations qui communiquent avec NetSuite via SOAP.
Pour chaque connexion, identifiez :
Les données d'activité sont utiles, mais elles ne suffisent pas. Une interface exécutée une fois par mois ou une fois par an peut tout de même être essentielle à un processus financier.
Les données d'utilisation permettent de savoir ce qui fonctionne. La validation métier permet de comprendre ce qui est important.
Les noms techniques des intégrations ne permettent pas toujours de comprendre leur véritable rôle.
Pour chaque intégration SOAP, déterminez :
Cette analyse est particulièrement importante pour les groupes européens qui disposent de plusieurs entités.
Une connexion qui échange peu de données peut malgré tout être critique pour un pays ou un processus financier spécifique.
Les actions à entreprendre peuvent être très différentes selon le type d'intégration.
Si votre équipe ou votre partenaire d'implémentation a développé l'intégration, il faut analyser les opérations SOAP existantes et déterminer comment les reproduire avec SuiteTalk REST Web Services ou des RESTlets.
Oracle recommande aux entreprises qui utilisent des applications SOAP personnalisées de commencer à planifier leur migration vers REST dès que possible.
Si l'intégration est maintenue par un autre éditeur logiciel, la question principale peut être la suivante :
Quand le fournisseur proposera-t-il une version basée sur REST et quels tests devrons-nous réaliser avant de l'adopter ?
Oracle recommande de contacter les fournisseurs d'applications SOAP développées par des partenaires afin de confirmer la disponibilité d'une solution de remplacement basée sur REST.
Il est essentiel d'identifier ces dépendances externes suffisamment tôt. Sans cela, une migration apparemment simple peut rester bloquée par le calendrier d'un fournisseur.
Lorsqu'une application utilisant SOAP est fournie par NetSuite, Oracle indique qu'une version basée sur REST sera mise à disposition.
Les entreprises doivent néanmoins suivre les modalités de remplacement et planifier les tests nécessaires pour accompagner cette transition.
Savoir qu'une intégration utilise SOAP ne suffit pas.
Il faut également identifier la version de l'endpoint WSDL utilisée et vérifier si elle est :
Les anciens endpoints passeront progressivement d'un statut pris en charge à un statut non pris en charge, avant d'être complètement désactivés.
La documentation Oracle sur les versions WSDL prises en charge doit donc être consultée lors de chaque évaluation des intégrations SOAP.
Cela soulève deux questions distinctes :
La mise à jour d'un ancien endpoint SOAP peut réduire les risques à court terme, mais elle ne remplace pas la nécessité de migrer vers une autre technologie avant la version 2028.2.
La transition de SOAP vers REST est également l'occasion de revoir l'authentification et la gouvernance des intégrations.
Pour chaque connexion, examinez :
Oracle recommande l'utilisation de REST Web Services avec OAuth 2.0 pour les nouvelles intégrations.
Changer d'API sans revoir la configuration globale des intégrations laisserait une partie de la dette technique existante intacte.
Une erreur fréquente consiste à supposer que chaque opération SOAP possède un équivalent REST identique.
Pour chaque intégration, il faut vérifier les enregistrements et les champs concernés, les opérations effectuées, les volumes de transactions attendus et la manière dont les erreurs sont gérées.
Les tests doivent couvrir l'ensemble du processus métier, et pas uniquement la réussite des appels API.
Pour un DSI, un CTO ou un responsable informatique, la fin de NetSuite SOAP ne représente pas uniquement une question de migration technique. Elle soulève également des enjeux de planification et de continuité d'activité.
Les principaux éléments à examiner sont :
Plus ces éléments sont clarifiés tôt, plus il sera facile d'allouer les ressources nécessaires et d'éviter que plusieurs migrations deviennent urgentes au même moment.
Les groupes européens utilisant NetSuite dépendent souvent d'intégrations entre plusieurs systèmes et pays.
Les connexions SOAP peuvent notamment prendre en charge :
Cela signifie que la priorisation des migrations ne doit pas reposer uniquement sur la complexité technique.
Une petite interface utilisée pour un processus financier propre à un pays peut présenter davantage de risques opérationnels qu'une synchronisation de données beaucoup plus importante.
Un modèle de priorisation pertinent doit combiner la criticité métier, la complexité de migration, les responsabilités et les risques liés aux échéances.
Plutôt que de regrouper toutes les interfaces dans un même plan de migration, répartissez-les en catégories claires :
Cette classification évite de consacrer du temps à migrer des intégrations qui devraient simplement être supprimées.
L'objectif n'est pas de convertir le plus grand nombre de connexions SOAP possible.
Il est de s'assurer que les intégrations dont l'entreprise a encore besoin disposent d'une solution de remplacement fiable.
Pour un petit nombre d'interfaces simples, une intégration directe avec REST peut être adaptée.
Dans un environnement applicatif plus complexe, la fin de SOAP peut également être l'occasion de se demander si les intégrations point à point restent pertinentes.
Une plateforme d'intégration en tant que service, ou iPaaS (Integration Platform as a Service), permet de centraliser les flux d'intégration, les transformations de données, la supervision et la gestion des erreurs, plutôt que de répartir cette logique entre plusieurs connexions personnalisées.
Le choix doit reposer sur une analyse de l'architecture, et non sur une décision systématique.
Le principal défi n'est souvent pas la conversion technique elle-même, mais la coordination.
Avant de remplacer une intégration, il peut être nécessaire de :
Lorsque plusieurs filiales et systèmes sont concernés, ces étapes prennent du temps.
Commencer dès maintenant ne signifie pas tout remplacer immédiatement. Il s'agit de réduire les incertitudes tant qu'il est encore possible de prendre des décisions éclairées.
Une fois l'audit terminé, les résultats doivent être transformés en une feuille de route opérationnelle.
Établir l'inventaire des intégrations et vérifier leur activité réelle.
Confirmer les responsables, les processus métier concernés, la criticité, le statut des endpoints et les dépendances.
Définir l'architecture cible : REST Web Services, RESTlet, solution de remplacement fournie par un éditeur ou iPaaS.
Développer les nouveaux flux et tester les processus métier de bout en bout.
Basculer les flux de production vers les nouvelles connexions, superviser les résultats et désactiver les intégrations SOAP obsolètes.
Un audit de préparation technique NetSuite (NetSuite Technical Upgrade Readiness Assessment) doit apporter davantage qu'un simple inventaire technique.
Les livrables attendus sont :
Ces éléments permettent aux équipes techniques et métier de partager une vision commune des actions à mener et de celles qui peuvent attendre.
Novutech accompagne les entreprises européennes en croissance dans l'évaluation de leur architecture NetSuite et la préparation des évolutions techniques.
Nos équipes peuvent analyser les intégrations SOAP existantes, les versions d'endpoints, l'activité, les méthodes d'authentification, les responsabilités et les dépendances, puis aider à définir un parcours de migration adapté vers SuiteTalk REST Web Services, des RESTlets ou une plateforme d'intégration lorsque cela est pertinent.
Avec plus de 250 clients, 65 consultants et 100 certifications, Novutech combine son expertise NetSuite à sa connaissance des intégrations et des processus financiers pour accompagner les entreprises, de l'audit initial aux actions correctives et au support à long terme.
Les Web Services SOAP de NetSuite disparaîtront avec la version 2028.2. Il s'agit d'une échéance liée à une version du logiciel, et non d'une date calendaire fixe.
Aujourd'hui, la démarche la plus utile ne consiste pas à migrer toutes les intégrations en même temps.
Elle consiste à savoir :
Une fois ces questions clarifiées, la fin de SOAP devient un projet de migration maîtrisable, plutôt qu'une urgence technique de dernière minute.
Vous ne savez pas quelles intégrations SOAP sont encore actives, quels processus métier en dépendent ou comment organiser leur migration vers REST ?
Novutech peut vous aider à établir un plan clair d'évaluation et de migration de vos intégrations NetSuite.
Oracle prévoit de supprimer les Web Services SOAP avec la version NetSuite 2028.2. Il s'agit d'une échéance liée à une version de NetSuite, et non d'une date calendaire fixe. Tous les endpoints SOAP seront alors désactivés et les intégrations qui les utilisent cesseront de fonctionner.
La documentation Oracle présente actuellement une différence sur ce point. Plusieurs pages consacrées aux WSDL mentionnent la version 2027.1, tandis que la FAQ officielle sur la suppression de SOAP indique 2027.2. Les entreprises doivent vérifier les informations les plus récentes d'Oracle concernant le cycle de vie des endpoints avant de planifier leur migration.
Oracle désigne SuiteTalk REST Web Services comme la solution de remplacement de SOAP et recommande l'utilisation de REST Web Services avec OAuth 2.0 pour les nouvelles intégrations.
Non. La priorité est d'abord d'identifier les connexions actives, de comprendre le statut de leurs endpoints et leur importance métier, puis de définir une stratégie de migration avant la suppression de SOAP.
Un audit doit fournir un inventaire validé des intégrations, une priorisation des risques, une recommandation de migration pour chaque connexion et une feuille de route opérationnelle pour les actions correctives.
Structurons vos systèmes pour clarifier vos décisions.
