Aller au contenu
SynapseTel CloudÉtat du service

Réservez un appel de 30 minutes

La prise de rendez-vous est gérée par Calendly, dont la politique de confidentialité s’applique aux informations saisies. Ouvrir dans Calendly

OSS télécom · Plateformes cloud hybride · Automatisation de la livraison

Migrations d’OSS télécom et plateformes de cloud hybride, livrées sous forme de changements que vous pouvez revoir, accepter ou arrêter

Pour les opérateurs mobiles et les équipes d’infrastructure d’entreprise confrontés à une migration Ericsson OSS-RC vers ENM, à une décision de plateforme OpenShift ou Kubernetes, à un renouvellement VMware ou à un déploiement d’automatisation exigeant un accès contrôlé. Les ingénieurs principaux portent l’architecture et le plan, les ingénieurs seniors sont affectés selon le périmètre, et votre autorité de changement décide de ce qui s’exécute.

Demander une revue d’architectureRéserver un appel
Consulter les livrables types du sprint

Ce que vous détenez après le Sprint d’évaluation de dix jours ouvrés, avant tout autre engagement.

  • Carte de topologie et de dépendances en directÉtat réel confronté à l’état documenté pour le périmètre convenu OSS/ENM, OpenShift ou VMware.
  • Séquence de migration et matrice de retour arrièreVagues ordonnées, contrôles préalables, critères d’arrêt et déclencheur de reprise pour chaque bascule.
  • Analyse d’écarts CI/CD et sécuritéSCC restricted-v2, moindre privilège RBAC et gestion des secrets, rapportés aux contrôles SOC 2, ISO 27001, PCI DSS ou télécom que vous nommez.
  • Architecture cible et modèle de coûtsDimensionnement, nomenclature et coût du maintien du parc actuel face à l’état cible.

Lire les exemples de dossiersPérimètre et tarif du sprint

Dirigé par
Des ingénieurs principaux responsables de l’architecture, de la méthode de procédure et de l’escalade sur chaque mission.
Réalisé par
Des ingénieurs seniors sélectionnés pour le périmètre et nommés dans votre énoncé de travaux avant tout engagement de dates.
Première réponse
Sous un jour ouvré
Première étape
Sprint d’évaluation de 2 semaines, 14 500 $US forfaitaires, crédité à 100 % sur un retainer annuel ou un contrat managé
Parc connecté

Trois couches d’ingénierie avec des chemins explicites pour les changements, l’exposition réseau et le retour opérationnel.

  1. T3

    Portails d’entreprise, API & plans de contrôle

    • Next.js / TypeScriptPortails clients · EN / ES / FR / HT
    • Consoles développeurs et NOCDemandes en libre-service · tableaux de bord SLO
    • Passerelle API CAMARAQoD · SIM Swap · Device Location
    • Identité d’entrepriseOIDC / RBAC · clés d’accès gérées par l’IdP

    Demande du portail → merge request → contrôles de politique → approbation humaine

  2. T2

    Livraison revue et MCP privé

    • Vérification préalable MCPOutils typés · points d’accès de modèles approuvés
    • GitLab CI et politiquesTrivy · SBOM · Cosign · OPA / Kyverno
    • Revue protégée et Argo CDApprobation humaine · réconciliation GitOps
    • Secrets et preuvesVault / ESO · événements SIEM expurgés

    Argo CD → état du cluster · CI / IaC runner → infrastructure hybride

  3. T1

    Infrastructures télécoms et hybrides

    • Ericsson OSS-RC / ENMGestion RAN / Core / IMS · médiation
    • Parc OpenShiftrestricted-v2 · Multus / SR-IOV
    • VMware / vSANConsolidation · bascule MTV → KubeVirt
    • Infrastructure hybrideTerraform / OpenTofu · VMware / Bare-Metal

La télémétrie des clusters, les reçus de pipeline et les événements d’outils expurgés reviennent aux consoles d’exploitation et au dépôt de preuves.

  • Politique de changement : validation restricted-v2 et approbation humaine avant la fusion
  • Preuves : SBOM, rapports d’analyse et de synchronisation capturés pendant le travail, lorsque dans le périmètre
  • Garde des données : aucune ; l’ingénierie s’exécute dans votre périmètre
Voir les composants de chaque niveau et les frontières que nous validons

Dirigé par des ingénieurs dont les fonctions antérieures en production étaient chez

  • Ericsson
  • Verizon
  • Zain
  • Digicel
  • Haitel
  • TempestNS

Le travail réalisé là-bas l’a été en tant que salariés de ces entreprises, non par SynapseTel Cloud. Aucun nom de client n’apparaît sur ce site.

Quand nous solliciter

Quatre situations pour lesquelles nous sommes organisés

Chacune a un déclencheur reconnaissable, une méthode que nous avons déjà appliquée et un ensemble défini de documents que vous conservez.

  1. Situation opérationnelle

    Un parc OSS hérité qui doit passer sur ENM

    Service associé: Exploitation Ericsson OSS et ENM

    Vous la reconnaissez quand
    Le support d’OSS-RC prend fin, les versions logicielles des nœuds dépassent le gestionnaire, et chaque flux northbound d’alarmes, de configuration et de performance a un consommateur que personne n’a cartographié.
    Ce que nous faisons
    Nous inventorions versions, nœuds et consommateurs d’interfaces, confirmons le chemin supporté par l’éditeur et rattachons les groupes de nœuds par vagues répétées, avec un déclencheur de retour arrière et un décideur nommé.
    Ce que vous obtenez
    Un plan de migration que votre comité de changement peut approuver, des comptes rendus de tests d’interface par vague et un parc ENM que votre équipe d’exploitation gère sans nous.
  2. Situation opérationnelle

    Une mise à niveau de plateforme que personne ne veut planifier

    Service associé: Kubernetes et Red Hat OpenShift

    Vous la reconnaissez quand
    La version d’OpenShift ou de Kubernetes prend du retard, les Operators et les budgets d’interruption ne sont pas vérifiés, et la dernière restauration d’etcd n’a jamais été répétée.
    Ce que nous faisons
    Nous vérifions la préparation par rapport à la version installée : compatibilité des Operators, marge des workers, âge des sauvegardes, durée de la fenêtre face au temps de drainage et à la marge de retour arrière. Bloquer, conditionner ou procéder, par écrit.
    Ce que vous obtenez
    Un compte rendu de préparation, une procédure de mise à niveau avec conditions d’arrêt et des preuves de reprise distinctes pour l’état du cluster et les données applicatives.
  3. Situation opérationnelle

    Un renouvellement VMware devenu une décision budgétaire

    Service associé: Modernisation VMware et vSAN

    Vous la reconnaissez quand
    L’exposition aux licences augmente, les politiques de stockage diffèrent d’un cluster à l’autre, et la date de renouvellement est plus proche que tout plan de migration.
    Ce que nous faisons
    Nous cartographions dépendances et compatibilité des charges, décidons par charge de conserver, réhéberger ou replateformer, et déplaçons les charges éligibles vers OpenShift Virtualization en vagues pilote puis de production.
    Ce que vous obtenez
    Une carte des dépendances, un plan par vagues avec responsables et contrôles d’acceptation, et un compte rendu de test de restauration pour les charges du périmètre.
  4. Situation opérationnelle

    Un flux d’automatisation qui exige un accès contrôlé

    Service associé: Agents IA et Intégration MCP

    Vous la reconnaissez quand
    Une tâche de NOC ou de livraison se fait encore à la main parce que l’automatisation qui pourrait l’exécuter aurait besoin d’un accès en écriture que personne ne veut accorder.
    Ce que nous faisons
    Nous commençons par un seul flux. Il reçoit des outils en lecture seule via des serveurs MCP à schéma restreint, des contrôles déterministes sur tout ce qu’il rédige et une personne qui approuve chaque action à conséquence.
    Ce que vous obtenez
    Une matrice d’outils et d’accès, des résultats d’évaluation sur des entrées normales, incomplètes et adverses, et un runbook de repli.

Services d’ingénierie de plateforme, de migration et de livraison

Nous migrons et soutenons les systèmes de gestion télécom et l’infrastructure hybride, automatisons la validation et le déploiement des charges, et construisons les portails et intégrations d’API réseau qui exposent ces plateformes à vos équipes et à vos clients.

T1

Infrastructure télécom et cloud hybride

Rattacher les nœuds OSS-RC historiques à Ericsson ENM, durcir les clusters OpenShift bare-metal et hybrides, et mener des migrations VMware vSAN et OpenShift Virtualization par vagues avec un retour arrière répété.

Cadrer une revue T1
Stack
  • Ericsson OSS & ENM
  • Kubernetes
  • Red Hat OpenShift
  • VMware & vSAN
Livrables et réception
MOPs de bascule ENM par vagues, manifestes avec SCC restricted-v2, plans de migration à chaud MTV/VDDK et socles d'infrastructure hybride résiliente.

Exploitation Ericsson OSS et ENM

Une bascule de gestionnaire qui perd des alarmes ou casse le provisionnement est un incident réseau, pas un glissement de projet. La migration doit préserver chaque flux de fautes, de configuration et de performance dont dépendent ses consommateurs.

Voir notre approche et le flux de livraison

Nous stabilisons, mettons à niveau et automatisons OSS-RC et ENM en environnements hybrides et cloud-native. Nous validons les éléments, automatisons les contrôles de configuration et d’alarmes et relions la gestion à l’orchestration.

  1. Éléments réseau
  2. OSS historique ou ENM
  3. Interfaces approuvées

Découvrez un exemple de périmètre. Nous convenons des interfaces, droits et critères d’acceptation avant livraison ; utilisez le design de la mission pour déployer.

Ce qui arrive dans vos dépôts

  • Runbooks de mise à niveau et bascule ENM
  • Contrôles de santé automatisés
  • Pipelines northbound d’alarmes et télémétrie
  • Preuves d’intégration FM/CM/PM
Découvrir Exploitation Ericsson OSS et ENM

Kubernetes et Red Hat OpenShift

Une mise à niveau qui s’arrête en plein drainage, ou une charge qui ne peut pas récupérer ses données, coûte plus que ce que la plateforme a économisé. La préparation doit être prouvée pour le cluster et pour chaque application séparément.

Voir notre approche et le flux de livraison

Nous concevons OpenShift et Kubernetes sur des hôtes bare-metal et VMware. La validation applicative couvre l’exécution non-root, les SCC restricted-v2 d’OpenShift, la segmentation CNI et les contrôles de cycle de vie day-2. Les Operators et composants d’infrastructure utilisent des permissions prises en charge par l’éditeur, avec des exceptions revues.

  1. Infrastructure
  2. Kubernetes ou OpenShift
  3. Charges applicatives

Découvrez un exemple de périmètre. Nous convenons des interfaces, droits et critères d’acceptation avant livraison ; utilisez le design de la mission pour déployer.

Ce qui arrive dans vos dépôts

  • Architecture OpenShift multicluster
  • Validation restricted-v2 Helm/Kustomize
  • Intégration et cycle de vie des Operators
  • Runbooks éprouvés de mise à niveau et reprise
Découvrir Kubernetes et Red Hat OpenShift

Modernisation VMware et vSAN

Une décision de renouvellement prise sans carte des dépendances devient une migration non planifiée. L’ordre des déplacements est fixé par les bases de données partagées, les travaux de sauvegarde et les contraintes de stockage, pas par la date de licence.

Voir notre approche et le flux de livraison

Nous auditons politiques vSphere/vSAN, réseau et dépendances VM pour migrer vers vSAN consolidé ou OpenShift Virtualization (KubeVirt). Nous utilisons la migration à chaud lorsque la compatibilité le permet et répétons les fenêtres de bascule pour les autres charges de travail.

  1. Calcul, réseau et stockage
  2. vSphere / vCenter / vSAN
  3. Workloads invités et reprise

Découvrez un exemple de périmètre. Nous convenons des interfaces, droits et critères d’acceptation avant livraison ; utilisez le design de la mission pour déployer.

Ce qui arrive dans vos dépôts

  • Carte des dépendances et impacts VM
  • Plan I/O et capacité vSAN
  • Vagues VMware vers OpenShift
  • Bascule et retour arrière validés
Découvrir Modernisation VMware et vSAN
T2

Contrôles de livraison et MCP privé

Remplacer les goulots d’étranglement des comités de changement par la réconciliation GitLab CI et Argo CD, des contrôles d’admission OPA/Kyverno et des pré-contrôles MCP à schéma restreint. Une personne approuve toujours chaque changement en production.

Cadrer une revue T2
Stack
  • AI Agents
  • MCP
  • CI/CD
  • Argo CD
  • Policy as Code
Livrables et réception
Promotions GitLab/Argo CD, OPA/Kyverno, images signées, SBOM et appels MCP auditables.

Agents IA et Intégration MCP

Une automatisation qui exige un accès en écriture que personne n’accordera reste manuelle. L’issue est un flux borné avec des outils en lecture seule et une personne qui approuve chaque action à conséquence.

Voir notre approche et le flux de livraison

Nous connectons l’IA privée aux dépôts, tickets et clusters via des serveurs Model Context Protocol (MCP) à schémas restreints. Les modèles restent dans votre périmètre approuvé ; des contrôles déterministes valident manifestes et restricted-v2 avant exécution approuvée.

  1. Événement métier
  2. Revue et approbation
  3. Action contrôlée

Découvrez un exemple de périmètre. Nous convenons des interfaces, droits et critères d’acceptation avant livraison ; utilisez le design de la mission pour déployer.

Ce qui arrive dans vos dépôts

  • Serveurs MCP à schémas restreints
  • Rapports de préparation et d’impact
  • Copilote GitLab / Argo CD
  • Traces SIEM et rétention
Découvrir Agents IA et Intégration MCP
T3

Portails d’entreprise, API et plans de contrôle

Portails développeurs internes, tableaux de bord opérationnels OSS, passerelles d’API réseau alignées sur CAMARA au-dessus d’une exposition NEF/SCEF autorisée par l’opérateur, et interfaces client en libre-service qui transforment des parcs backend complexes en parcours rapides et auditables, en Next.js et TypeScript.

Cadrer une revue T3
Stack
  • Next.js
  • React
  • TypeScript
  • CAMARA
  • NEF / SCEF
  • API Integrations
  • Custom Portals
Livrables et réception
Contrats CAMARA, adaptateurs NEF/SCEF autorisés, OAuth2/OIDC et parcours multilingues.

Exemples de livrables

  • Portail Next.js / TypeScript
  • Passerelle OpenAPI / CAMARA
  • OAuth2/OIDC et RBAC par tenant
  • Livraison accessible EN / ES / FR / HT
Découvrir Portails d’entreprise, API et plans de contrôle

Nous convenons par écrit des systèmes couverts, des accès et des responsabilités. Les heures de support, l’astreinte d’urgence et les objectifs de réponse sont précisés pour chaque engagement. Les noms de technologies n’impliquent ni partenariat ni certification.

Demander une revue d’architectureComparer les engagementsVoir les exemples de livrables

Trouver le service adapté

Choisissez votre technologie et l’aide recherchée. Vos choix seront repris dans le formulaire de demande.

Choisissez une technologie et un type de mission pour continuer.

Instantanés d’ingénierie

Travaux livrés par nos ingénieurs

Trois missions anonymisées issues des fonctions antérieures de nos ingénieurs, décrites par stack, problème et résultat. Aucun client n’est nommé et aucun ne peut être identifié par élimination.

  • OSS opérateur et plateforme de conteneurs

    Charges télécom et intégrations ENM migrées vers OpenShift

    Des charges de gestion héritées et leurs intégrations northbound ont été replateformées sur Red Hat OpenShift par vagues répétées. Les flux d’alarmes, de configuration et de performance ont été tracés jusqu’à leurs consommateurs avant chaque bascule, avec validation préalable automatisée et un déclencheur de retour arrière par vague.

    • Ericsson ENM
    • Red Hat OpenShift
    • Bascule répétée

  • DevSecOps et automatisation d’audit

    Des portes policy-as-code à la place des revues manuelles pré-audit

    Les listes de contrôle manuelles avant mise en production ont été remplacées par des contrôles de politique et une vérification des manifestes assistée par IA dans les pipelines GitOps. Chaque changement portait ses propres preuves d’analyse, de politique et d’approbation, et le temps de revue est allé aux exceptions plutôt qu’à la paperasse.

    • Argo CD
    • Agents MCP
    • Policy as code

  • Consolidation de datacenter hybride

    Des parcs vSAN et cloud fragmentés sous un seul plan déclaratif

    Des clusters VMware vSAN distincts et des services cœur cloud ont été réunis sous un modèle d’exploitation déclaratif unique, la restauration étant répétée par groupe de charges avant le retrait des anciens parcs.

    • VMware vSAN
    • Cloud hybride
    • Terraform

Livré par nos ingénieurs en tant que salariés de leurs organisations précédentes, non par SynapseTel Cloud. Noms de clients, chiffres et détails identifiants sont retenus. Comment nous prouvons la livraison

Expertise et preuves

Qui dirige le travail, et ce que vous pouvez examiner avant de vous engager

Aucun nom ni logo de client n’apparaît sur ce site, et nous n’en inventons pas à la place. Ce que nous pouvons montrer : qui est responsable, d’où vient son expérience et le matériel que nous publions.

Qui dirige le travail

Télécom, OpenShift et automatisation de la livraison
Porte la conception des migrations OSS-RC et ENM, les décisions de plateforme OpenShift et VMware et chaque méthode de procédure.
Plateformes cloud, DevSecOps et applications
Est responsable des fondations de clusters OpenShift, des pipelines de politiques GitLab et Argo CD, de l’outillage MCP et des applications opérateur.

Les ingénieurs seniors sont sélectionnés pour chaque périmètre et nommés dans l’énoncé de travaux. Un ingénieur principal reste responsable de l’architecture, des approbations et de l’escalade du premier appel jusqu’à la passation.

Fonctions antérieures
Ericsson, Verizon, Zain, Digicel, Haitel et TempestNS. Le travail réalisé là-bas l’a été en tant que salariés de ces entreprises, non par SynapseTel Cloud.
Direction technique sur la page Entreprise

Ce que vous pouvez examiner dès maintenant

  1. Rédigé par nousNotes de décisionNotes techniques sur les contrôles de migration ENM, les mises à jour EUS d’OpenShift, les décisions de sortie de VMware, les permissions MCP et la conception des SLA, rédigées par les ingénieurs qui dirigent les missions.
  2. Modèle illustratifExemples de documents d’ingénierieModèles de méthode de procédure, d’audit de préparation et de procès-verbal d’acceptation avec exemples travaillés. Illustratifs, pas des résultats clients.
  3. Démonstration synthétiqueContrôle de préparationLes règles de préparation aux mises à niveau exécutées sur des données inventées : marge des workers, budgets d’interruption, âge des sauvegardes, durée de fenêtre face au temps de drainage.
  4. Produit réel, données d’exemplePortail clientLe portail que votre équipe utiliserait pour les incidents, demandes, devis et factures, présenté avec des enregistrements d’exemple étiquetés.
  5. Politique en vigueurPolitique de sécurité et d’exploitationContrôles de garde des données, d’accès, d’infrastructure et de gouvernance de l’IA, avec une synthèse imprimable.
  6. Faits en vigueurSynthèse achatsEntité contractante, conditions publiées, prérequis d’accès, acceptation et escalade sur une seule page.

Les topologies, procédures et références propres à une mission sont partagées pendant la découverte cadrée, lorsqu’un client l’a accepté.

Modèle de livraison

Deux principaux nommés, responsables du cadrage à la passation

Chaque mission est assurée par un binôme principal : un responsable télécom et infrastructure hybride (T1) et un responsable DevSecOps, MCP privé et applications (T2/T3). Tous deux sont nommés dans l’énoncé de travaux, et les principaux qui cadrent le travail le livrent eux-mêmes.

ÉtapeVotre organisationResponsable T1 · télécom et infrastructure hybrideResponsable T2/T3 · DevSecOps, MCP et applications
CadrageDécrit les systèmes, les contraintes et le résultat attenduCadre le parc ENM, OpenShift et VMware/vSAN et son accès en lecture seuleCadre les pipelines, les limites MCP et les portails d’exploitation, et fixe dates et livrables avec le responsable T1
Architecture et planVotre autorité de changement revoit et approuveResponsable de l’architecture d’infrastructure cible, des vagues de migration et de chaque condition d’arrêtResponsable des contrôles CI/CD, de la politique en tant que code et des vérifications préalables MCP que tout changement doit passer
ExécutionVos ingénieurs sont présents ; un enregistrement d’approbation précède chaque étapeExécute les étapes ENM, cluster et stockage approuvées et surveille les conditions d’arrêtLivre les changements en merge requests via vos contrôles CI et Argo CD ; tout écart est une nouvelle décision prise avec votre décideur
AcceptationAccepte au regard des critères écritsValide les preuves d’infrastructure et les registres de retour arrièreConsigne résultats, exceptions et runbooks dans vos dépôts
Escalade et continuitéContact nommé sur la liste d’escaladePoint d’escalade pour les incidents réseau et plateformePoint d’escalade pour les incidents de pipelines, de portails et d’API
Responsabilités au fil d’une mission. Les responsables du binôme, les heures mensuelles combinées, les heures de support et les critères d’acceptation sont fixés dans l’énoncé de travaux avant le démarrage.
  • Les objectifs de réponse sont distincts des objectifs de rétablissement, et les heures de support sont distinctes de l’astreinte d’urgence. Chacun est indiqué à côté de l’option de mission concernée.
  • Le binôme, ce sont deux principaux, pas un vivier. Dans un Retainer Plateforme, il fournit de 100 à 120 heures principales combinées par mois sur un chantier à la fois ; un second chantier simultané est une extension distincte, convenue par écrit.
  • Documentation, runbooks et preuves restent dans vos dépôts, de sorte que le travail continue si les personnes changent.
Standards de livraison et exemples de documentsSynthèse achats

Étape par étape

Comment se déroule une mission

Chaque étape se termine par du travail revu dans vos dépôts et une décision qui vous appartient.

  1. Découverte et audit des dépendances (semaines 1–2)

    Inclus dans le Sprint d’évaluation à 14 500 $US

    Nous nous connectons via votre bastion ou votre passerelle ZTNA pour inspecter la configuration des clusters, les politiques de stockage vCenter et vSAN, les pipelines CI/CD et les journaux de changement, et nous consignons les modes de défaillance et les points uniques de défaillance identifiés.

    Jalon 01

    Artefacts livrés

    • Carte de topologie et de dépendances en direct
    • Registre des modes de défaillance et des points uniques de défaillance
    • Relevé des accès et des prérequis

  2. Architecture cible et plan de bascule

    Restitution au jour 10 · forfait du sprint crédité à 100 % sur un contrat annuel

    Vous recevez une spécification de l’état cible avec la source Mermaid (.mmd), un ordre de migration séquencé, des déclencheurs de retour arrière pour chaque vague et une comparaison des coûts avec le maintien du parc actuel.

    Jalon 02

    Artefacts livrés

    • Spécification de l’état cible avec dimensionnement
    • Ordre de migration séquencé avec un déclencheur de retour arrière par vague
    • Comparaison des coûts face au maintien du parc actuel

  3. Construction et câblage des pipelines

    Retainer Plateforme · 24 000 $US/mois ou 240 000 $US/an (20 000 $US/mois effectif)

    Les modules Terraform, les manifestes OpenShift, les serveurs MCP et les applications Next.js arrivent dans vos dépôts GitLab ou GitHub derrière des contrôles de politique que votre équipe peut lire et maintenir.

    Jalon 03

    Artefacts livrés

    • Modules Terraform ou OpenTofu et manifestes OpenShift
    • Portes de politique, serveurs MCP et applications Next.js dans vos dépôts
    • Preuves du pipeline : SBOM, rapports d’analyse et évaluations de politique

  4. Exploiter et assurer : transfert ou managé

    Transfert, ou Orchestration Managée à partir de 34 500 $US/mois

    Choisissez le modèle d’exploitation. En build-operate-transfer, nous exploitons le parc avec votre équipe jusqu’à ce qu’elle en prenne la charge, puis nous remettons les runbooks. En exploitation managée, nous restons pour les mises à niveau du cycle de vie, la correction des dérives dans les pipelines et l’astreinte d’urgence 24/7, avec un SLA de disponibilité contractuel au niveau 99.9% ou 99.99%.

    Jalon 04

    Artefacts livrés

    • Relevés de bascule et vérifications des niveaux de service après migration
    • Sessions de transfert des runbooks enregistrées
    • Plan de build-operate-transfer ou contrat d’exploitation managée

Chaque jalon se termine de la même façon : du travail revu dans vos dépôts et une décision qui vous appartient : continuer, suspendre ou arrêter.

Comment un changement se déroule

Un seul parcours du changement, de la référence à l’acceptation

Chaque vague de migration, mise à niveau de plateforme et déploiement d’automatisation que nous menons suit les mêmes cinq étapes. Sélectionnez une étape pour voir ses contrôles, les interfaces qu’elle touche et où se situe votre approbation.

Scénario illustratifRattachement d’un groupe de nœuds RAN d’Ericsson OSS-RC vers ENM. Les chiffres sont inventés pour montrer la méthode ; ce n’est pas de la télémétrie client.
Sélectionner une étape
Contrôles
  • Versions installées et modèles de nœuds consignés face à la matrice de compatibilité du fournisseur
  • Responsables nommés pour chaque système, interface et approbation de changement
  • Instantanés actuels des alarmes, KPI et configurations conservés comme état initial
Interfaces concernées
Lecture seule : northbound CM/FM/PM d’ENM, politiques vCenter et vSAN, API Kubernetes, configuration CI/CD
Limite d'approbation
Comptes nominatifs en lecture seule via votre bastion ou passerelle ZTNA. Aucune donnée de production ne quitte le parc.
Ce qui est déposé dans votre dépôt
Inventaire et carte des dépendances validés comme documents revus
Dans le scénario
Inventaire du groupe de nœuds avec versions source et cible consignées ; compteurs PM référencés sur les sept jours précédents.
Contrôles
  • Compatibilité des versions source, cible et nœuds face à la documentation du fournisseur
  • Chaînes de certificats, enrôlement PKI/CMPv2 et droits de licence en place
  • Durée de la fenêtre face aux durées répétées par étape, plus le temps de retour arrière
Interfaces concernées
Documentation du fournisseur, inventaires de certificats et de licences, enregistrements de changements précédents
Limite d'approbation
Les constats bloquants arrêtent la planification. Les conditions sont listées avec un responsable et une échéance.
Ce qui est déposé dans votre dépôt
Synthèse de préparation avec constats validés, conditionnels et bloquants
Dans le scénario
Un blocage : chaîne de certificats incomplète sur trois nœuds. Replanifié après ré-enrôlement ; fenêtre confirmée avec marge de retour arrière.
Contrôles
  • Méthode de procédure avec ordre des étapes, vérification après chaque étape et conditions d’arrêt
  • Scripts, overlays et configuration de médiation sous forme de merge request dans votre dépôt
  • Vos portes CI et contrôles de politique passent ; un décideur nommé approuve
Interfaces concernées
Votre dépôt GitLab ou GitHub, votre pipeline CI et votre comité des changements
Limite d'approbation
Rien ne s’exécute sans votre enregistrement d’approbation. Nous proposons ; votre autorité de changement décide.
Ce qui est déposé dans votre dépôt
Merge request approuvée et méthode de procédure signée
Dans le scénario
Procédure de rattachement revue avec le responsable du NOC ; déclencheur de retour arrière fixé à 30 minutes sans synchronisation des alarmes.
Contrôles
  • Chaque étape vérifiée face à son état attendu avant de lancer la suivante
  • Contrôles d’alarmes, de KPI et de configuration comparés à la référence pendant la fenêtre
  • Conditions d’arrêt et déclencheur de retour arrière surveillés par le décideur nommé
Interfaces concernées
Accès en écriture uniquement pour les étapes convenues, dans la fenêtre convenue, en présence de vos ingénieurs
Limite d'approbation
Le périmètre se limite à la procédure approuvée. Tout écart est une nouvelle décision, pas une improvisation.
Ce qui est déposé dans votre dépôt
Journal d’exécution horodaté avec chaque résultat de vérification
Dans le scénario
Nœuds rattachés en deux lots ; synchronisation FM confirmée en 12 minutes par lot ; aucun déclencheur de retour arrière atteint.
Contrôles
  • État final comparé à la référence : alarmes, KPI, dérive de configuration
  • Critères d’acceptation de l’énoncé des travaux signés par votre responsable
  • Enregistrement de décision de retour arrière et runbook remis, quelle que soit l’issue de la fenêtre
Interfaces concernées
Les mêmes interfaces en lecture seule que la référence ; vos systèmes de tickets et de documentation
Limite d'approbation
L’acceptation est votre décision face à des critères écrits. Les conditions ouvertes restent visibles jusqu’à leur clôture.
Ce qui est déposé dans votre dépôt
Enregistrement d’acceptation, enregistrement de décision de retour arrière et runbook mis à jour
Dans le scénario
Compteurs PM dans la tolérance de référence ; deux alarmes cosmétiques documentées avec responsable et échéance ; session de passation enregistrée.
Essayer le contrôle de préparation synthétiqueLire les enregistrements typesApprofondir sur la page architecture

Les noms d’étapes et les contrôles sont notre méthode de travail. Vos fenêtres de maintenance, votre autorité de changement et vos critères d’acceptation sont écrits dans l’énoncé des travaux avant toute exécution.

Par où commencer

Commencez à la phase où vous êtes

Un parc se modernise rarement en une séquence propre. Vous pouvez avoir besoin d’un audit des dépendances avant un renouvellement d’hyperviseur, d’une vague de migration vers OpenShift ou de contrôles de livraison pour un cluster déjà en production. Chaque option a ses propres livrables et conditions.

  1. Point d’entrée · Parc non cartographié

    Sprint d’évaluation

    14 500 $USforfait fixe · sprint intégré de 2 semaines

    Commencez ici lorsque
    Vous devez cartographier les dépendances et les points de défaillance avant d’engager un budget pour un renouvellement d’hyperviseur, une migration ou de nouveaux contrôles de livraison.
    Livrables habituels
    Versions et dépendances, architecture cible, plan par vague, contrôles de bascule et critères de reprise.
    Conditions
    Dix jours ouvrés une fois l’accès en lecture seule en place. Le forfait complet est crédité sur un Retainer Plateforme annuel ou un contrat annuel d’Orchestration Managée signé dans les 30 jours suivant la fin du sprint.
    Consulter les livrables types du sprint

    Ce que vous détenez après le Sprint d’évaluation de dix jours ouvrés, avant tout autre engagement.

    • Carte de topologie et de dépendances en directÉtat réel confronté à l’état documenté pour le périmètre convenu OSS/ENM, OpenShift ou VMware.
    • Séquence de migration et matrice de retour arrièreVagues ordonnées, contrôles préalables, critères d’arrêt et déclencheur de reprise pour chaque bascule.
    • Analyse d’écarts CI/CD et sécuritéSCC restricted-v2, moindre privilège RBAC et gestion des secrets, rapportés aux contrôles SOC 2, ISO 27001, PCI DSS ou télécom que vous nommez.
    • Architecture cible et modèle de coûtsDimensionnement, nomenclature et coût du maintien du parc actuel face à l’état cible.

    Lire les exemples de dossiersPérimètre et tarif du sprint

    Périmètre illustratif et inclusions

    Exemple de point de départ

    Vous avez besoin d’un plan directeur et d’un audit de dépendances pour moderniser votre environnement OSS/ENM ou cloud hybride, avec une mise en œuvre chiffrée séparément.

    • Revue intégrée de deux semaines couvrant l’infrastructure T1, les pipelines T2 et les portails T3.
    • Audit en direct de la topologie et du rayon d’impact du périmètre convenu Ericsson OSS/ENM, OpenShift, VMware/vSAN ou cloud hybride.
    • Architecture cible rédigée, avec schémas sources Mermaid (.mmd) téléchargeables.
    • Ordre de migration vague par vague avec plans de retour arrière, critères d’arrêt et matrice de risques « coût de l’inaction ».
    • Restitution pour la direction et l’ingénierie, avec un backlog à périmètre fixe pour la phase 2.
    Demander ce point de départConsulter le périmètre et les tarifs

  2. Jalon : travail revu dans vos dépôts ; vous continuez, suspendez ou arrêtez.

    Point d’entrée · Backlog défini

    Retainer Plateforme

    24 000 $US/ mois

    Commencez ici lorsque
    Vous êtes prêt à déplacer des charges par vagues répétées, à ajouter des contrôles de livraison à un cluster déjà en production ou à construire une application opérateur sur un backlog convenu.
    Livrables habituels
    Socles de plateforme Terraform/OpenTofu, manifestes Helm/Kustomize, vagues de migration MTV, golden paths GitLab/Argo CD, outillage MCP privé de pré-contrôle et consoles opérateur Next.js, livrés sur le backlog convenu.
    Conditions
    Facturation mensuelle. Réponse sous quatre heures ouvrées pendant les heures de support : du lundi au vendredi, de 8 h à 18 h heure de l’Est, hors jours fériés.
    Périmètre illustratif et inclusions

    Exemple de point de départ

    Vous avez un backlog convenu de migrations hybrides, d’automatisation et de portails internes ou d’API à livrer.

    • Binôme principal : 1 responsable infrastructure télécom/hybride et 1 responsable DevSecOps/MCP/applications, avec 100 à 120 heures principales combinées par mois.
    • Un seul chantier de modernisation actif à la fois, avec des commits hebdomadaires dans vos dépôts via votre processus de revue.
    • Exécution T1–T3 : durcissement OpenShift restricted-v2, médiation ENM, bascules de VMware vers KubeVirt ou portails Next.js/CAMARA.
    • Gouvernance automatisée : GitLab CI, policy-as-code OPA/Kyverno, GitOps Argo CD et contrôles préalables via un MCP privé restreint par schéma.
    • Revue trimestrielle d’architecture et FinOps avec votre direction.
    • SLA en heures ouvrées : objectif de réponse d’ingénierie de quatre heures, du lundi au vendredi, de 8 h à 18 h, heure de l’Est.
    Demander ce point de départConsulter le périmètre et les tarifs

  3. Jalon : travail revu dans vos dépôts ; vous continuez, suspendez ou arrêtez.

    Point d’entrée · Parc en exploitation

    Orchestration Managée

    À partir de 34 500 $US/ mois

    Commencez ici lorsque
    Vous avez besoin d’une exploitation continue d’une plateforme migrée ou d’un parc multi-fournisseurs, avec cycle de vie, correction de dérive et astreinte d’urgence 24/7.
    Livrables habituels
    Cycle de vie OSS/éléments, correction de dérive, procédures, traces de politiques et revues mensuelles.
    Conditions
    Chiffré par parc. Astreinte d’urgence 24/7, objectifs de réponse et de rétablissement, et un SLA de disponibilité contractuel dans votre contrat.
    Périmètre illustratif et inclusions

    Exemple de point de départ

    Votre plateforme migrée ou votre environnement multifournisseur nécessite une exploitation continue et une escalade 24 h/24.

    • Tout le Retainer Plateforme, plus la réponse aux incidents par astreinte d’urgence 24/7/365.
    • Des ingénieurs principaux nommés sur votre compte, sans file d’attente L1 à niveaux.
    • SLA de disponibilité contractuel au niveau 99.9% ou 99.99%, défini selon le parc couvert et les limites de ses dépendances.
    • Gestion multifournisseur des éléments sur la médiation RAN/Core, le parc OpenShift et le stockage hybride.
    • Pipeline continu de preuves d’audit et de conformité vers votre SIEM ou votre dépôt de preuves pour les contrôles convenus ; il soutient votre audit sans constituer une certification.
    • Responsable dédié de la livraison et de la fiabilité, avec revues mensuelles des SLO et du budget d’erreur.
    Demander ce point de départConsulter le périmètre et les tarifs

Les exemples servent de point de départ illustratif. Nous convenons par écrit de la capacité, de la couverture, des livrables et des objectifs de service avant le début des travaux. Cloud, licences et tiers sont facturés séparément, et une migration définie peut aussi être menée sous un SOW de projet sur mesure.

Portail client

Découvrez le portail avant de signer

Utilisez le portail client pour suivre les incidents, demandes, devis et factures de votre prestation. Nous partageons les mêmes dossiers de service que votre équipe.

Visiter le portail client
Données d’exemple
Exemple de vue d’ensemble du portail client : incidents ouverts par gravité, heures de forfait restantes ce mois-ci et éléments en attente du client.
Ouvrir l’écran d’exemple en grand (nouvel onglet)

Découvrez le portail avant de signer

Données d’exemple

Exemple de vue d’ensemble du portail client : incidents ouverts par gravité, heures de forfait restantes ce mois-ci et éléments en attente du client.

Gouvernance et autorité d’ingénierie

Le cadre de chaque mission

  • Validation OpenShift restricted-v2 avant la fusion
  • Images signées, SBOM et portes de politique
  • Preuves d’audit pour les contrôles SOC 2, ISO 27001, PCI DSS ou télécom convenus
  • Aucune garde de données de production
  • Approbation humaine à chaque changement en production

Les preuves soutiennent votre audit sans constituer une certification. Les noms de technologies n’impliquent aucun partenariat.

Accès direct à un ingénieur principal

Chaque demande est lue par un ingénieur principal, et le principal qui cadre le travail le dirige du premier appel jusqu’à la passation. Les ingénieurs seniors sont nommés dans l’énoncé de travaux. Pas de couche commerciale, pas de passation à une équipe junior.

Opéré depuis: Floride, États-Unis.

Politique de sécurité et d’exploitationAperçu achats

Dites-nous ce qui casse

Décrivez la forme du problème. Un ingénieur principal, pas un commercial, répond sous un jour ouvré avec un périmètre proposé pour un Sprint d’évaluation de deux semaines, ou une autre étape si le sprint ne convient pas.

Demander une revue d’architectureVoir les tarifs et les retainers

La suite

  1. Décrire le parc : la frontière T1, T2 ou T3 concernée et le goulot d’étranglement actuel
  2. Revue par un ingénieur principal : une réponse technique écrite sous un jour ouvré
  3. Une séance de travail de 30 minutes, puis un SOW à périmètre fixe pour le Sprint d’évaluation à 14 500 $US
Première réponse
Sous un jour ouvré
Engagement
L’appel de revue cadre le travail. Le Sprint d’évaluation est une mission distincte à prix fixe, chiffrée avant tout paiement.
Confidentialité
NDA mutuel avant toute inspection de topologie ou de dépôt