Migration Avaya SBC : remplacer le SBCE sans perturber la voix
Les déploiements Avaya SBCE continuent de faire passer les appels. C’est rarement le problème. La conversation autour de la migration commence généralement lorsque quelque chose change autour du SBCE : un second dépôt de bilan au titre du Chapter 11 rouvre la question du risque fournisseur, une paire de SBCE atteint le plafond de 2 000 sessions et déclenche une expansion de licence imprévue, un avis de fin de vente de Carrier Services impose de toute façon un changement côté SIP trunk, ou le devis de renouvellement Core Suite arrive sans prix par session que l’équipe achats puisse modéliser. Aucun de ces déclencheurs n’exige de toucher à Communication Manager, Session Manager ou Aura. Le SBC est un composant unique en bordure de réseau, et dans de nombreux déploiements, il peut être remplacé indépendamment du reste de l’infrastructure voix.
Cette page est le guide opérationnel pour passer d’ Avaya SBCE à ProSBC. Elle part du principe que la décision d’évaluer un remplacement a été prise et détaille ce à quoi ressemble concrètement la migration en production : comment auditer la configuration SBCE existante, comment les objets de configuration Avaya correspondent à ceux de ProSBC, comment faire fonctionner les deux SBC en parallèle en toute sécurité, et comment planifier une bascule avec un véritable chemin de retour arrière.
Ce qui déclenche une migration Avaya SBCE en 2026
Le déclencheur de migration est généralement l’un de quatre événements spécifiques, et non une insatisfaction générale envers la plateforme. Savoir lequel s’applique détermine comment le projet est délimité et à quel point le calendrier doit être serré.
La réévaluation du risque fournisseur est le déclencheur le plus fréquemment évoqué en 2026. Avaya a déposé le bilan au titre du Chapter 11 en 2017, puis de nouveau en février 2023, épongeant cette fois environ 75 % de sa dette de 3,4 milliards de dollars et en ressortant 76 jours plus tard. L’organisation post-restructuration est plus légère, la direction stratégique est davantage orientée vers le cloud et les offres par abonnement, et certains clients ont commencé à réévaluer la manière dont ils souhaitent gérer la dépendance à long terme envers une infrastructure sur site. Rien de tout cela ne signifie automatiquement que le SBCE va disparaître, mais cela change la façon dont les équipes achats, risques et continuité répondent à la question de savoir si le SBC en bordure de réseau doit dépendre de ce fournisseur en particulier.
Le plafond de 2 000 sessions concerne tout environnement dont les volumes d’appels augmentent. Les déploiements SBCE sont généralement dimensionnés autour d’une architecture de 2 000 sessions par serveur, ce qui signifie qu’une croissance au-delà de ce seuil peut nécessiter des instances SBCE supplémentaires, des licences supplémentaires et une charge de gestion accrue. Les opérateurs qui atteignent le plafond le découvrent généralement lors d’un pic d’heure de pointe qui déclenche une conversation imprévue sur les licences. Un SBC logiciel capable de monter jusqu’à 60 000 sessions par serveur réduit tout ce problème à un changement de configuration.
La licence opaque sous le modèle d’abonnement est le troisième facteur. Avaya a fait passer le SBCE à un abonnement obligatoire, avec des sessions groupées en ratio 7:1 Standard/Advanced sous licence Core Suite, sans prix par session publié. Prévoir les coûts SBC sur trois et cinq ans nécessite une conversation de devis qui dépend du reste du contrat Avaya. Les équipes achats et finances qui modélisent le TCO sur un cycle OPEX trouvent de plus en plus difficile de justifier cette opacité en interne.
Les signaux de fin de vente autour du portefeuille Avaya élargi constituent le quatrième facteur. Le SIP Trunking Avaya Carrier Services a une date limite de migration publiée en septembre 2025, et d’autres lignes de produits sont passées en fin de vente durant la même période. Le SBCE lui-même n’a pas été déclaré en fin de vente au moment de la rédaction, mais la tendance de rationalisation fait de « planifier un remplacement maintenant, selon notre calendrier, pendant que tout fonctionne encore » l’option la plus sûre plutôt que d’attendre une lettre de notification.
Si le déclencheur s’applique à une seule paire SBCE dans un parc Avaya plus large, la migration peut être limitée à cet élément. Aura, Communication Manager, Session Manager, les plans de numérotation et le reste de la pile Avaya restent en place. Le SBC est le seul composant qui change.
Phase 0 : inventorier ce qui est sur le SBCE aujourd’hui
Toute migration SBC réussie commence par un audit honnête de la configuration actuelle. Sauter cette étape est la cause la plus fréquente de surprises lors de la bascule. Le livrable n’est pas une capture d’écran de l’EMS Avaya SBCE, mais une liste structurée qui se mappe proprement sur ce que le SBC de remplacement doit recevoir comme configuration.
Extrayez les éléments suivants du SBCE existant avant de toucher à quoi que ce soit d’autre.
Comptages de sessions réels. Exportez 90 jours de CDR et trouvez le nombre réel de sessions simultanées en pointe, pas le maximum licencié. De nombreux déploiements SBCE fonctionnent bien en dessous du plafond de 2 000 sessions, ce qui signifie que le remplacement peut être dimensionné selon l’utilisation réelle plutôt que la capacité nominale. ProSBC prend en charge des déploiements jusqu’à 60 000 sessions par serveur, le dimensionnement est donc généralement dicté par les exigences de déploiement plutôt que par les limites matérielles brutes.
L’inventaire des Server Configuration. Listez chaque Server Configuration sur le SBCE : trunks opérateurs, pairs Session Manager, groupes de trunk Communication Manager, intégrations centre de contacts ou CPaaS, plateformes d’enregistrement ou d’analyse, et points de test internes. Pour chacun, capturez le transport (UDP, TCP, TLS), l’adresse et le port, ainsi que le Routing Profile, la Media Rule, la Signaling Rule et le TLS Profile auxquels il est lié dans l’End Point Flow.
Le catalogue des Media Rule et Signaling Rule. Documentez les préférences de codecs, la politique SRTP et TLS, les intervalles keep-alive OPTIONS, la gestion de l’early media, le comportement DTMF et toute particularité par côté. Un déploiement SBCE réel possède généralement moins de jeux de règles distincts que de Server Configurations, et un même jeu de règles est souvent réutilisé pour plusieurs pairs.
Scripts SigMa et Routing Profiles. Exportez chaque script SigMa et chaque Routing Profile. C’est la partie de la configuration qui porte le plus de logique métier : réécritures de P-Asserted-Identity pour des opérateurs spécifiques, normalisation de l’en-tête From pour Aura, transformations de plan de numérotation, étiquetage d’attestation pour STIR/SHAKEN, etc. Tout ce qui n’est pas identifié et recréé pendant la migration peut affecter le comportement après la bascule, les scripts non étiquetés ou non documentés méritent donc une attention explicite maintenant plutôt que pendant le fonctionnement en parallèle.
Topology Hiding Profiles, TLS Profiles et ACL. Capturez chaque Topology Hiding Profile, chaque certificat TLS et sa date d’expiration, chaque liste d’adresses IP autorisées ou refusées, chaque Application Rule et tout seuil DDoS. Le TLS en particulier nécessite une gestion soignée, car la chaîne de certificats sur le nouveau SBC doit satisfaire les mêmes pairs en amont et en aval sans briser l’authentification mutuelle.
Intégrations STIR/SHAKEN et antifraude. Si le SBCE signe ou vérifie via un STI-AS externe, ou si une plateforme antifraude y est connectée, documentez le service de signature, les certificats et la politique d’attestation. Ces éléments sont les plus susceptibles de nécessiter une approche architecturale différente sur ProSBC, où la signature et la détection de fraude s’intègrent directement dans le flux de routage plutôt que d’exister comme éléments de configuration par trunk.
Phase 1 : mapper les objets Avaya SBCE sur les objets ProSBC
La plus grande source de friction lors de la migration n’est pas le réseau, c’est le modèle de configuration. Avaya et ProSBC décrivent les mêmes fonctions SBC sous-jacentes avec des objets différents, et les ingénieurs qui exécutent la migration ont besoin d’un modèle mental fonctionnel de la correspondance avant de commencer la construction en laboratoire.
Le tableau ci-dessous couvre les objets présents dans chaque déploiement SBCE. La correspondance est conceptuelle, pas une équivalence ligne par ligne, et la colonne de droite capture la différence pratique qui affecte la façon dont la configuration est traduite.
| Objet Avaya SBCE | Équivalent ProSBC | Ce qui change en pratique |
|---|---|---|
| Server Configuration | NAP (Network Access Point) | Correspondance un pour un. Le NAP regroupe le transport, l’adresse, la liste de codecs, le SRTP et les paramètres ACL que le SBCE répartit entre Server Configuration, Media Rule et Signaling Rule. |
| Media Rule | Paramètres média du NAP | Les préférences de codecs, la politique SRTP et l’ancrage média s’intègrent dans le NAP lui-même. Il n’y a pas d’objet Media Rule séparé à maintenir en parallèle. |
| Signaling Rule | Paramètres de signalisation du NAP et SIP Profile | Le keep-alive OPTIONS, le traitement des requêtes, le traitement des réponses et le comportement SIP par côté s’intègrent au NAP. ProSBC traite les paramètres de signalisation comme des propriétés du NAP plutôt que comme un objet de règle partagé. |
| Topology Hiding Profile | Configuration de masquage de topologie du NAP | Le masquage de topologie devient un paramètre par NAP. Il n’y a pas d’objet profil séparé à réutiliser entre pairs. |
| SigMa Script | Routing Script (Ruby module) | Le plus grand changement conceptuel. Le langage de script propriétaire d’Avaya devient Ruby, avec l’avantage de requêtes HTTP externes, de logique conditionnelle sur n’importe quel paramètre d’appel, et la possibilité d’intégrer la détection de fraude, le LNP et STIR/SHAKEN dans la décision de routage elle-même. |
| Routing Profile | Table de routage plus Routing Script | Les entrées de routage simples se mappent directement. Le routage conditionnel (basculement opérateur, routage par heure, moindre coût) est implémenté dans le Routing Script plutôt que sous forme d’entrées supplémentaires de Routing Profile. |
| End Point Flow (Server / Subscriber Flow) | Correspondance IP source du NAP plus logique de routage | La décision « quelle configuration s’applique à quel trafic » passe d’un objet Flow à la combinaison de règles de correspondance NAP et du Routing Script. La classification entrante devient une correspondance source explicite par NAP. |
| Application Rule | Limites de sessions du NAP et seuils DDoS | Les limites de sessions par pair et les seuils DDoS s’intègrent au NAP. Les seuils globaux se trouvent dans la configuration au niveau système. |
| TLS Profile | Configuration TLS du NAP et magasin de certificats | Les certificats sont téléversés une fois et référencés par NAP. Le mTLS pour Teams Direct Routing ou pour les trunks opérateurs suit le même modèle que sur le SBCE. |
| External STIR/SHAKEN signing | Routing Script signing module | Le STIR/SHAKEN de ProSBC passe par le moteur de routage et s’intègre aux fournisseurs STI-AS externes (TransNexus ClearIP, Neustar ou tout service de signature HTTP) avec des points de terminaison primaires et secondaires et un repli P-Identity-Bypass. L’attestation devient une décision par appel plutôt qu’un paramètre par trunk. |
| EMS (Element Management System) | Portail Web ProSBC plus API | La gestion à panneau unique se consolide dans le Portail Web ProSBC. L’orchestration multi-éléments est gérée par l’API plutôt que par un produit de gestion séparé. |
La correspondance n’est pas la migration. C’est le contrat sur lequel les trois phases suivantes s’appuient.
Phases 2 à 4 : le plan de migration
Le plan ci-dessous suppose une seule paire SBCE remplacée par une seule instance ProSBC (avec ProSBC+ pour la haute disponibilité 1+1). Les déploiements SBCE multi-éléments suivent le même schéma élément par élément. L’ensemble de la séquence s’étend généralement sur quatre à huit semaines, du laboratoire à la bascule, selon le nombre d’opérateurs distincts et d’intégrations Aura dans le périmètre.
Phase 2 : construction en laboratoire
Déployez une instance ProLab sur le même segment réseau que le SBCE. La licence ProLab est gratuite en permanence, offre trois sessions simultanées et se provisionne en une vingtaine de minutes. Utilisez le laboratoire pour reproduire une Server Configuration côté opérateur, un pair Session Manager ou Communication Manager, et toute logique SigMa associée traduite en Ruby. L’objectif de la phase laboratoire est de valider la correspondance du tableau de configuration ci-dessus par rapport au dialecte SIP spécifique que l’opérateur actuel et le côté Aura envoient réellement, et non de recréer la configuration de production complète.
Si Teams Direct Routing est dans le périmètre du SBCE aujourd’hui, testez le mTLS, le SRTP et le flux OPTIONS SBC-vers-Teams avec un tenant de test. La certification Teams compte comme case à cocher achats dans certaines organisations : ProSBC prend en charge Teams Direct Routing et est déployé en production dans des environnements Teams DR, mais n’a pas obtenu la certification formelle de Microsoft. Si une exigence stricte de certification existe, la liste Microsoft publiée fait référence.
Phase 3 : réplication
Une fois que la construction en laboratoire a validé la correspondance, construisez la configuration de production complète sur l’instance ProSBC. Reproduisez chaque NAP à partir de l’inventaire des Server Configuration, transférez les listes de codecs et la politique SRTP depuis les Media Rules, et convertissez les scripts SigMa en logique de module Ruby. C’est là que le temps passe, et c’est la phase qui bénéficie le plus d’un inventaire Phase 0 propre.
Téléversez les certificats TLS et configurez les paramètres TLS au niveau du NAP. Si TLS et SRTP sont requis de bout en bout, validez les suites de chiffrement et les suites cryptographiques SRTP par rapport à ce que les opérateurs et Aura négocient réellement, et non ce que la configuration SBCE semble indiquer. Les écarts entre la politique configurée et le trafic observé sont la deuxième cause la plus fréquente de surprises lors de la bascule.
Si la signature STIR/SHAKEN est dans le périmètre, pointez le script de routage vers le même service de signature externe que le SBCE utilise aujourd’hui, ou vers un fournisseur différent si la migration est le bon moment pour changer. Configurez les URL de signature primaire et secondaire et confirmez le comportement de repli P-Identity-Bypass.
Phase 4 : fonctionnement en parallèle
Gardez le SBCE en production. Acheminez un trunk opérateur via ProSBC tandis que tous les autres trunks restent sur le SBCE. Deux à quatre semaines de fonctionnement en parallèle permettent généralement de détecter les cas limites que les tests en laboratoire ne peuvent pas reproduire : un en-tête P-Charge-Info inhabituel d’un opérateur spécifique, un comportement de renégociation de codec en heure de pointe, un intervalle OPTIONS différent de la valeur documentée, un comportement d’en-tête spécifique à Session Manager que le SBCE gère silencieusement, ou un code de réponse SIP spécifique pour lequel ProSBC nécessite une règle explicite.
Comparez les taux de complétion d’appels, les scores MOS, la précision des CDR et les niveaux d’attestation STIR/SHAKEN entre les deux chemins pendant la période de fonctionnement en parallèle. Si un script SigMa s’avère faire un travail que personne n’a documenté, le découvrir sur cinq pour cent du trafic est bien mieux que sur la totalité.
Bascule
Planifiez la bascule pendant une fenêtre de maintenance avec le SBCE sous tension et prêt. Déplacez les trunks opérateurs restants un par un, en validant chacun avant de passer au suivant. Mettez à jour les enregistrements DNS et toute référence de routage en amont pour pointer vers le ProSBC.
Laissez le SBCE sous tension et accessible pendant au moins trente jours. C’est le chemin de retour arrière. Si un problème impactant les clients apparaît après la bascule, réacheminer le trafic vers le SBCE est un changement réseau plutôt qu’un projet de récupération. Après la fenêtre de validation, décommissionnez le châssis SBCE ou l’instance virtuelle et annulez la ligne Core Suite au prochain renouvellement.
Validation post-bascule
Les soixante-douze premières heures après la bascule constituent la fenêtre de validation la plus productive. Trois vérifications comptent le plus.
La réconciliation des CDR vérifie si les enregistrements d’appels sur le nouveau SBC correspondent au volume et au profil de l’ancien. Comparez les comptages d’appels heure par heure, la durée moyenne des appels et la distribution des codes de disposition entre la dernière semaine complète sur le SBCE et les trois premiers jours sur ProSBC. Une divergence pointe généralement vers une règle SigMa qui n’a pas survécu au mappage plutôt que vers un problème réseau.
La validation des seuils antifraude est importante spécifiquement parce que les règles de détection de fraude calibrées sur le comportement du SBCE peuvent soit se déclencher excessivement, soit manquer des schémas sur le nouveau SBC. Si le scoring de fraude en temps réel est intégré via TransNexus ClearIP, SecureLogix ou YouMail, surveillez attentivement la première semaine de décisions et ajustez les seuils en fonction des faux positifs observés.
La continuité de supervision couvre toute la télémétrie qui sortait du SBCE : traps SNMP, flux syslog, flux CDR RADIUS ou intégration avec les produits de gestion d’éléments Avaya. ProSBC expose des métriques par NAP et par appel qui s’intègrent à Datadog, Prometheus, un SIEM ou un service de supervision géré. Confirmez que les tableaux de bord lisent le nouveau flux avant de déclarer la bascule terminée.
Pièges courants de migration
À travers les migrations MSP, FAI, centre de contacts et entreprises, quatre pièges reviennent plus que tous les autres. Aucun n’est une surprise technique isolée, mais chacun tend à coûter un jour ou deux s’il n’est pas anticipé.
Logique SigMa non documentée. Les déploiements SBCE accumulent des règles de réécriture d’en-têtes au fil des années, souvent ajoutées par des personnes qui ont depuis quitté l’équipe. Traiter les scripts existants comme faisant autorité sans comprendre pourquoi chacun existe est le moyen le plus rapide de casser un opérateur spécifique lors de la bascule. La bonne approche est de passer en revue chaque script SigMa pendant la Phase 0 et d’étiqueter ceux dont l’objectif n’est pas évident pour des tests explicites pendant la Phase 4.
Gestion des P-headers spécifiques à Aura. Session Manager et Communication Manager produisent un comportement SIP avec des P-headers propriétaires, des particularités de gestion de session et des patterns OPTIONS spécifiques à Avaya. Le SBCE normalise une grande partie de cela silencieusement. Le module de routage Ruby sur ProSBC nécessite des règles explicites pour le même comportement, et tester en laboratoire contre une véritable instance Aura, et non un point de test SIP générique, est ce qui fait remonter ces problèmes à temps pour les corriger.
Transfert de chaînes de certificats TLS. Les SBCE et leurs pairs en amont négocient parfois des chaînes de certificats qui incluent des intermédiaires que le SBCE sert automatiquement. Lorsque le même certificat est déplacé vers ProSBC, la configuration de la chaîne doit être explicite. Testez le mTLS pour tout trunk opérateur sécurisé par TLS et pour Teams Direct Routing en laboratoire avant de vous y fier en production.
Hypothèses de licence groupée. Le ratio 7:1 Standard/Advanced d’Avaya signifie que l’équipe qui exécute la migration n’a parfois pas une image claire de quels appels consommaient des sessions Advanced sur le SBCE. Sur ProSBC, où chaque session est identique à partir de seulement 1,40 $ par session par an, le modèle de planification devient un seul chiffre plutôt qu’un ratio. Confirmez le mix réel des fonctionnalités « équivalent Advanced » utilisées avant de dimensionner le remplacement pour que la conversation comparative avec les finances reste ancrée.
Questions fréquemment posées
Combien de temps dure généralement une migration Avaya SBCE ?
Quatre à huit semaines, de l’audit Phase 0 à la bascule complète, est la fourchette typique pour une migration mono-élément. La Phase 0 et la Phase 1 (audit et mappage) prennent généralement une à deux semaines, la Phase 2 (construction en laboratoire) environ une semaine, la Phase 3 (réplication de la configuration complète) deux à trois semaines selon la complexité des scripts SigMa, et la Phase 4 (fonctionnement en parallèle) deux à quatre semaines. La bascule elle-même tient dans une seule fenêtre de maintenance. Les parcs SBCE multi-éléments évoluent linéairement : chaque paire SBCE remplacée ajoute son propre travail de Phase 3 et Phase 4.
ProSBC interopérera-t-il avec notre Avaya Aura, Session Manager et Communication Manager existants ?
Oui. ProSBC est un B2BUA en bordure de réseau qui gère le comportement SIP côté Aura via le même moteur de manipulation SIP utilisé pour la normalisation côté opérateur. Session Manager, Communication Manager, les plans de numérotation et le reste de la pile Aura continuent de fonctionner tels quels. Il s’agit d’un remplacement de SBC, pas d’un remplacement d’Aura, et le périmètre de migration s’arrête en bordure de réseau.
Devons-nous modifier nos contrats SIP trunk ou la configuration opérateur ?
Non. ProSBC fonctionne avec n’importe quel fournisseur SIP trunk, et les contrats opérateurs restent inchangés. Les opérateurs continuent de terminer les trunks vers l’adresse IP que le SBC leur présente. Seul l’équipement au milieu change, ce qui rend le périmètre de bascule suffisamment restreint pour être planifié et inversé proprement.
Qu’advient-il de notre configuration STIR/SHAKEN pendant la migration ?
ProSBC implémente la signature et la vérification STIR/SHAKEN via son moteur de routage Ruby, en s’intégrant aux fournisseurs STI-AS externes (TransNexus ClearIP, Neustar ou tout service de signature HTTP). Pendant la migration, le service de signature peut rester le même, ou cela peut être le moment d’évaluer un fournisseur différent. Les points de terminaison de signature primaire et secondaire assurent la redondance, et un repli P-Identity-Bypass garantit que les appels ne sont pas perdus si le service de signature est brièvement indisponible. L’attestation devient une décision par appel dans le script de routage plutôt qu’une configuration par trunk.
ProSBC peut-il fonctionner sur le même hyperviseur que celui utilisé pour le SBCE aujourd’hui ?
Le SBCE prend en charge VMware et certaines plateformes cloud. ProSBC fonctionne sur VMware, KVM, Proxmox, AWS, Azure et bare metal. Si le déploiement SBCE est sur VMware, AWS ou Azure, ProSBC fonctionne sur la même plateforme. KVM et Proxmox sont disponibles comme alternatives gratuites pour les équipes souhaitant réduire les licences d’hyperviseur dans la même migration. La haute disponibilité 1+1 native sur Azure nécessite une configuration supplémentaire par rapport au comportement prêt à l’emploi sur VMware et KVM, ce qu’il vaut mieux faire remonter pendant la Phase 2 plutôt que de le découvrir pendant la Phase 4.
Que faire si nous n’avons pas l’expertise SBC interne pour gérer la migration ?
TelcoBridges propose un Service Géré qui prend en charge la migration de bout en bout : audit Phase 0, mappage de configuration, déploiement ProSBC, gestion du fonctionnement en parallèle et exécution de la bascule. Le Service Géré inclut ProSBC+ avec haute disponibilité 1+1, support 24h/24 7j/7 et supervision continue. Il est hébergé soit sur l’infrastructure TelcoBridges, soit sur une plateforme choisie par le client (AWS, Azure, VMware ou KVM), le client conservant un accès complet. Pour les équipes sans ingénieurs SBC dédiés, c’est généralement la bonne approche : le coût d’une migration gérée représente une fraction du coût d’embauche d’un spécialiste SBC interne.
Quel est le plan de retour arrière si quelque chose tourne mal après la bascule ?
Le SBCE reste sous tension et accessible pendant au moins trente jours après la bascule. Si un problème impactant les clients apparaît dans cette fenêtre, réacheminer le trafic vers le SBCE est un changement réseau plutôt qu’un projet de récupération. Le plan en quatre phases est spécifiquement conçu autour de ce chemin de retour arrière : le SBCE n’est jamais décommissionné tant que ProSBC n’a pas été validé sous trafic de production réel pendant plusieurs semaines. La plupart des migrations n’ont jamais besoin du retour arrière, mais le fait de l’avoir en place est ce qui rend le fonctionnement en parallèle et la bascule sûrs à exécuter.
Commencez la migration Avaya SBCE par un laboratoire, pas par un engagement
La façon la moins risquée d’évaluer si ProSBC convient à un environnement Avaya SBCE existant est de déployer une instance ProLab et de reproduire une Server Configuration contre un véritable opérateur ou un véritable pair Session Manager. La licence ProLab est gratuite en permanence, offre trois sessions simultanées et se provisionne en une vingtaine de minutes. Aucun engagement commercial n’est requis pour démarrer.
Pour les équipes qui préfèrent une évaluation guidée, le Service Géré couvre la migration complète : audit, mappage, déploiement, fonctionnement en parallèle, bascule et opérations continues.
Vous comparez les approches d’abord ? Consultez Remplacer un SBC matériel par un logiciel pour le cas plus large de transition matériel vers logiciel.
Vous préférez évaluer par vous-même d’abord ? Démarrez votre essai gratuit de 30 jours.