Guide complet OTCA — OpenTelemetry
OpenTelemetry Certified Associate · Programme, plan de révision, ressources, examen blanc gratuit.
L'OpenTelemetry Certified Associate (OTCA) valide les competences fondamentales en observabilite cloud-native avec OpenTelemetry, le standard CNCF pour traces, metriques et logs. Destinee aux ingenieurs SRE, DevOps, observabilite et developpeurs backend, elle se passe en ligne sous forme de QCM de 60 questions en 90 minutes. Aucun prerequis formel, mais une experience en systemes distribues est recommandee. Debouches principaux : SRE, ingenieur observabilite, platform engineer, avec salaires de 55 a 85 KEUR en France.
Pourquoi passer la certification OTCA ?
En 2026, l'observabilite est devenue un pilier strategique des architectures cloud-native, et OpenTelemetry s'impose comme le standard de facto au sein de la CNCF, ayant atteint le statut Graduated en 2024. Passer l'OTCA en 2026 represente un investissement strategique pour plusieurs raisons. D'abord, OpenTelemetry est desormais adopte par Datadog, New Relic, Grafana, Splunk, AWS, Azure et GCP, creant une demande explosive pour des profils maitrisant ce standard unifie. Le marche francais affiche plus de 3500 offres mentionnant OpenTelemetry, avec une croissance annuelle de 180 pourcent. Ensuite, la cert valorise immediatement le CV face aux recruteurs : c'est la premiere certification officielle CNCF dediee a l'observabilite, lancee fin 2024. Le ROI est rapide : augmentation salariale moyenne de 12 a 18 pourcent constatee dans les 12 mois post-certification. Enfin, elle complete parfaitement les certs CKA, CKAD ou Prometheus Certified Associate (PCA), formant un socle SRE/Platform Engineering tres recherche. Les entreprises migrant depuis des solutions proprietaires (vendor lock-in) recherchent activement ces profils pour piloter leurs strategies multi-cloud et hybrides en 2026.
Caractéristiques de l'examen
| Format | QCM 60 questions |
|---|---|
| Duree | 90 minutes |
| Score requis | 75% |
| Prix officiel | 250 EUR (250 USD) |
| Langues | Anglais (francais non disponible en 2026) |
| Validite | 3 ans |
| Prerequis | Aucun prerequis formel, experience recommandee en systemes distribues et observabilite |
Programme détaillé par domaine
Domain 1 : OpenTelemetry Fundamentals & Architecture 22%
- Objectifs
- Ce domaine evalue la comprehension globale du projet OpenTelemetry, son positionnement au sein de la CNCF, sa gouvernance et son architecture generale. Le candidat doit savoir expliquer la fusion entre OpenTracing et OpenCensus, comprendre les specifications stables vs experimentales, identifier les composants principaux (API, SDK, Collector, Protocol) et leur role respectif. Il faut maitriser le concept de signal (trace, metric, log) et savoir differencier instrumentation manuelle, automatique et zero-code. Comprendre le modele de donnees OTLP et la philosophie vendor-neutral est essentiel.
- Concepts clés
- Specification OTel, signals (traces, metrics, logs, profiling beta), OTLP (OpenTelemetry Protocol) en gRPC et HTTP, semantic conventions, resource attributes, context propagation, W3C Trace Context, baggage, exporters, processors, receivers. Comprendre la difference entre API (interface stable) et SDK (implementation). Connaitre les statuts de stabilite : stable, experimental, deprecated. Maitriser le modele resource/scope/signal et la separation des responsabilites entre instrumentation, traitement et export. Notion de telemetry pipeline et architecture push vs pull.
- Services / outils
- OTLP gRPC port 4317, OTLP HTTP port 4318, W3C Trace Context, B3 propagator, Jaeger propagator. SDK officiels : Java, Python, Go, JavaScript, .NET, Ruby, PHP, Rust, Swift, C++. Outils CLI : otel-cli, telemetrygen.
- Temps estimé
- 10-12h
Domain 2 : Traces & Distributed Tracing 25%
- Objectifs
- Ce domaine couvre en profondeur le tracing distribue, signal historique d'OpenTelemetry. Le candidat doit savoir creer des spans manuellement et automatiquement, gerer les relations parent-enfant, ajouter attributes, events et links. La propagation de contexte entre services est centrale : maitriser l'injection et l'extraction des headers, le format W3C traceparent et tracestate. Comprendre les strategies de sampling (head-based, tail-based, probabilistic, parent-based) et leurs impacts sur la performance et le cout. Savoir diagnostiquer un trace incomplet ou casse.
- Concepts clés
- Span, SpanContext, TraceId (16 bytes), SpanId (8 bytes), trace flags, span kinds (SERVER, CLIENT, PRODUCER, CONSUMER, INTERNAL), span status (OK, ERROR, UNSET), span events, span links. Sampling : AlwaysOn, AlwaysOff, TraceIdRatioBased, ParentBased. Propagators : TraceContextPropagator, BaggagePropagator, composite propagator. Batch span processor vs simple span processor. Semantic conventions HTTP, database, messaging, RPC.
- Services / outils
- Jaeger, Zipkin, Tempo (Grafana), AWS X-Ray, Google Cloud Trace, Azure Monitor. Auto-instrumentation agents : Java agent, Python opentelemetry-instrument, Node.js require hook. Bibliotheques contrib : instrumentation-http, instrumentation-express, instrumentation-flask.
- Temps estimé
- 14-16h
Domain 3 : Metrics & Logs 20%
- Objectifs
- Ce domaine evalue la maitrise des signaux metrics (stable depuis 2023) et logs (stable depuis 2024). Le candidat doit comprendre les types d'instruments (Counter, UpDownCounter, Histogram, Gauge, Observable variants), le concept d'aggregation temporality (cumulative vs delta) et les views permettant de customiser les metriques. Pour les logs, il faut comprendre le LogRecord, le bridge API permettant d'integrer log4j, logback, Python logging, et la difference entre logs structures et non structures.
- Concepts clés
- Synchronous instruments : Counter, UpDownCounter, Histogram, Gauge. Asynchronous instruments : ObservableCounter, ObservableUpDownCounter, ObservableGauge. MeterProvider, Meter, View, aggregation, exemplars. Histogram buckets et explicit bucket boundaries. LogRecord, severity number/text, body, attributes. Bridge API pour logs legacy. Correlation traces-logs via TraceId injection. Resource detection automatique (k8s, host, container, process).
- Services / outils
- Prometheus, Prometheus Remote Write, Mimir, Thanos, Cortex, Victoria Metrics. Loki, Elasticsearch, OpenSearch, Splunk. PrometheusExporter (pull), OTLPMetricExporter (push). Log appenders : Logback OTel, Log4j2 OTel, Python LoggingHandler.
- Temps estimé
- 12-14h
Domain 4 : OpenTelemetry Collector 23%
- Objectifs
- Le Collector est un composant central de l'examen. Le candidat doit savoir deployer le Collector en mode agent (sidecar/daemonset) et gateway, configurer le pipeline YAML avec receivers, processors et exporters. Comprendre les distributions (core vs contrib), le builder OCB pour creer une distribution custom. Maitriser les processors critiques : batch, memory_limiter, attributes, resource, filter, transform, tail_sampling. Savoir diagnostiquer un Collector via zpages, pprof, health_check extension.
- Concepts clés
- Receivers (otlp, jaeger, zipkin, prometheus, hostmetrics, kubeletstats, filelog), processors (batch, memory_limiter, attributes, resource, filter, transform, tail_sampling, probabilistic_sampler, k8sattributes), exporters (otlp, otlphttp, prometheus, prometheusremotewrite, loki, debug, file). Extensions : health_check, pprof, zpages, file_storage. OCB (OpenTelemetry Collector Builder). Mode agent vs gateway. OTTL (OpenTelemetry Transformation Language).
- Services / outils
- OpenTelemetry Operator pour Kubernetes, Helm charts officiels, Docker images otel/opentelemetry-collector et otel/opentelemetry-collector-contrib. Endpoints : 4317 (gRPC), 4318 (HTTP), 13133 (health), 1777 (pprof), 55679 (zpages), 8888 (metrics internes).
- Temps estimé
- 14-16h
Domain 5 : Instrumentation & Best Practices 10%
- Objectifs
- Ce domaine transverse evalue les bonnes pratiques d'instrumentation en production. Le candidat doit choisir entre auto-instrumentation et instrumentation manuelle, comprendre l'impact performance, gerer les secrets et donnees sensibles (PII scrubbing), respecter les semantic conventions pour garantir l'interoperabilite. Connaitre les patterns d'integration en microservices, l'instrumentation des frameworks populaires et le debugging d'une chaine d'observabilite cassee.
- Concepts clés
- Semantic conventions (HTTP, DB, messaging, FaaS, k8s), resource attributes (service.name, service.version, deployment.environment), cardinality control, PII scrubbing via attributes processor, sampling strategy en production, cost optimization, overhead measurement, zero-code instrumentation. Best practices : ne jamais instrumenter en synchrone bloquant, toujours utiliser batch processor, configurer memory_limiter en premier.
- Services / outils
- OpenTelemetry Operator (auto-injection sidecar), instrumentation annotations Kubernetes, opentelemetry-instrument CLI Python, -javaagent JVM, Node.js --require @opentelemetry/auto-instrumentations-node/register.
- Temps estimé
- 8-10h
Plan de révision hebdomadaire
Plan de revision sur 8 semaines pour un profil DevOps/SRE avec experience cloud-native. Semaine 1 : lire la documentation officielle opentelemetry.io, sections Concepts et Specification. Comprendre l'architecture generale, les signals et l'histoire du projet. Installer un environnement local avec Docker Compose (collector + Jaeger + Prometheus + Grafana). Semaine 2 : approfondir le tracing. Instrumenter manuellement une application Python ou Go avec traces, jouer avec span attributes, events, links. Tester les propagators W3C. Semaine 3 : explorer les metrics. Implementer Counter, Histogram, Gauge. Configurer Prometheus exporter et visualiser dans Grafana. Comprendre cumulative vs delta. Semaine 4 : maitriser les logs OTel et la correlation traces-logs via TraceId. Tester les bridge APIs. Semaine 5 : focus Collector. Deployer en mode agent et gateway, ecrire des configurations YAML complexes avec OTTL, configurer tail_sampling, k8sattributes processor. Builder une distribution custom avec OCB. Semaine 6 : auto-instrumentation et OpenTelemetry Operator sur Kubernetes (kind ou minikube). Tester l'injection automatique via Instrumentation CRD. Semaine 7 : semantic conventions approfondies, best practices production (cardinality, PII, performance). Lire les case studies CNCF. Semaine 8 : examens blancs (KodeKloud, KillerCoda OTel scenarios, simulateurs communautaires). Reviser les points faibles, refaire des configs Collector a blanc. Le jour J : repos, hydratation, environnement calme pour les 90 minutes d'examen surveille en ligne.
Besoin d'un planning sur mesure ? 30 jours · 60 jours · 90 jours
Ressources recommandées
Source primaire indispensable : specification complete, guides par langage, documentation Collector et semantic conventions a jour.
Curriculum officiel detaillant les objectifs d'examen par domaine et leur ponderation exacte, mis a jour par la Linux Foundation.
Cours video complet avec labs interactifs Killercoda, scenarios pratiques Collector et instrumentation multi-langages.
Canal #otel-certifications sur CNCF Slack, retours d'experience candidats, SIG meetings hebdomadaires et discussions techniques.
5 erreurs classiques à éviter
- Erreur 1 : Confondre OpenTelemetry et OpenTracing/OpenCensus. OTel est la fusion des deux, OpenTracing et OpenCensus sont archives depuis 2019. Reviser l'historique et la timeline officielle pour repondre correctement aux questions de contexte.
- Erreur 2 : Negliger la difference API vs SDK. L'API est stable et utilisee dans le code applicatif, le SDK est l'implementation runtime configurable. Les bibliotheques tierces doivent dependre uniquement de l'API, jamais du SDK.
- Erreur 3 : Mal configurer l'ordre des processors dans le Collector. memory_limiter doit toujours etre EN PREMIER, suivi des processors de transformation, puis batch en dernier avant export. Inverser cet ordre cause des OOM en production.
- Erreur 4 : Oublier les semantic conventions. Utiliser des attributes custom (http_method au lieu de http.request.method) casse l'interoperabilite avec les backends et les dashboards standards. Toujours verifier la spec semconv officielle.
- Erreur 5 : Sous-estimer le sampling. Activer AlwaysOn en production explose les couts et la charge backend. Comprendre tail_sampling (decision apres trace complete) vs head_sampling (decision a l'origine) est crucial pour l'examen et la pratique.
5 questions types corrigées
Carrière & salaire après OTCA
L'OTCA ouvre des postes tres demandes en 2026 : SRE Observability (55-75 KEUR junior, 75-95 KEUR senior en France), Platform Engineer (60-90 KEUR), Ingenieur DevOps specialise observabilite (65-85 KEUR), Solutions Architect cloud-native (80-120 KEUR). A Paris et grandes metropoles, les salaires montent de 10 a 15 pourcent. En remote europeen (Allemagne, Pays-Bas, Suisse), comptez 80-130 KEUR. Les certifications complementaires recommandees forment un parcours coherent : CKA (Kubernetes Administrator), CKAD, Prometheus Certified Associate (PCA), Grafana Certified Professional, et a plus haut niveau le Kubestronaut (5 certs CNCF). Les recruteurs CNCF, finance, e-commerce et editeurs SaaS recherchent activement ces profils pour leurs initiatives de modernisation et reduction du vendor lock-in observabilite.
FAQ — OTCA
Combien de temps faut-il pour preparer OTCA ?
Comptez 60 a 80 heures de preparation pour un profil DevOps/SRE avec experience cloud-native, soit environ 8 semaines a raison de 8-10h/semaine. Pour un debutant en observabilite, prevoyez 100-120 heures sur 12 semaines.
Cette certification est-elle reconnue en France ?
Oui, l'OTCA est delivree par la Linux Foundation et la CNCF, organismes mondialement reconnus. Elle est de plus en plus citee dans les offres d'emploi francaises, notamment chez OVHcloud, Doctolib, Criteo, Capgemini, Sopra Steria et les grandes banques (BNP, SG, CA).
Quel est le taux de reussite a OTCA ?
Officiellement non communique par la CNCF, mais les retours communautaires indiquent un taux d'environ 65-70 pourcent au premier passage, comparable au CKA. Une preparation serieuse avec labs pratiques augmente significativement les chances de reussite.
Quel est le salaire apres OTCA ?
En France 2026 : 55-75 KEUR pour un profil junior SRE/observabilite, 75-95 KEUR pour un senior, jusqu'a 110-130 KEUR pour un Staff/Principal Engineer specialise. Les remunerations en remote europeen sont superieures de 15-25 pourcent.
Faut-il une experience prealable ?
Aucun prerequis formel, mais une experience de 1-2 ans en systemes distribues, conteneurs (Docker/Kubernetes) et observabilite (Prometheus, Grafana, ELK) est fortement recommandee pour reussir confortablement.
OTCA ou cert concurrente : laquelle choisir ?
OTCA est la seule cert officielle vendor-neutral sur OpenTelemetry. Les alternatives (Datadog, Splunk, New Relic, Dynatrace) sont vendor-specific. Pour un profil generaliste, OTCA est prioritaire ; pour un poste sur une stack vendor specifique, complementez avec la cert correspondante.
Combien coute l'examen OTCA ?
Le prix officiel est de 250 USD (environ 250 EUR), souvent en promotion a 199 USD lors de KubeCon ou Cyber Monday. Le tarif inclut un retake gratuit en cas d'echec au premier passage, valable 12 mois.
Combien de fois peut-on repasser OTCA ?
L'inscription inclut un free retake (1 nouvelle tentative gratuite) si vous echouez au premier essai. Au-dela, il faut racheter une inscription complete. Il n'y a pas de limite au nombre total de tentatives, mais respecter un delai de 14 jours entre chaque passage.
Prêt à passer à la pratique ?
Lancez votre examen blanc gratuit ou faites le test d'orientation pour valider votre choix.
Démarrer l'examen blanc OTCA → Test d'orientation