Experience

Lead Dev NetDevOps · Bouygues Télécom

I'm the Lead Dev on a 14-strong NetDevOps team at Bouygues Télécom, working on network automation around Cisco NSO. The team has its own manager and product owner, so my role is a technical one: I set the direction the developers build against, and I run the technical round when the team hires. Most of those developers come from software rather than networking, which is why the team keeps three network referents — I'm one of them, so I carry domain authority on the network we automate, not only on the code that automates it.

Most of my energy goes into making sure those developers spend the bulk of their time on high-value business work, and as little as possible on repetitive, low-value tasks.

Background

Automation

Most of what I build is internal tooling, and nearly all of it replaces something that was already in place — without disrupting the people who depended on it; a good part of it runs on GitLab CI. It also has to carry the network knowledge the developers don't have: the checks and guardrails below are what let people without an operator background work safely on a national ISP's network.

Releases

170+ NSO packages in production, all shipped through the same infra-as-code pipeline, driven by a single YAML source of truth. Once the YAML is committed and the prod branch tagged, pre-checks, code and NED deployment, package reload and post-checks run in 15 minutes — against at least 3 hours of hands-on work before, taking us from at most one production release a month to two or three.

nem

The NSO Environment Manager: spins up a complete NSO environment from a YAML file, in CI or on a developer's machine (here, one NSO package is one GitLab repo). I replaced the sequential Ansible playbook and Cisco's own sequential dependency resolver with an asyncio engine modelled on theirs, cutting CI test job times by 35% on average and up to 50%.

For developers it put an end to silent environment drift — nem status reports each package's branch, commit and position against its remote, nem sync brings the whole environment back up to date in one command, and the nem init --from-mr line now added to every merge request lets any reviewer rebuild the author's exact environment. Used directly by 15–30 developers, and by 50+ people through CI.

Onboarding

Getting a new developer set up used to demand real Linux fluency: installing NSO by hand, creating the workspace with ncs-project, downloading the NEDs, building the netsims — roughly four hours. nem now drives the whole chain: one DevContainer per project, built from the very image the CI runs on, then the NSO environment spun up inside it from the YAML — so a developer's environment and the pipeline's are the same thing. Under three minutes, once uv is installed and an SSH key is registered on GitLab.

Testing

A test framework of my own, driven entirely through NSO's RESTCONF API. The PyATS setup it replaced diffed an XML payload loaded over the CLI against an expected file, and could only reach services; mine describes each scenario as a sequence of typed tasks — free-form config or RESTCONF calls with any path and payload, plus built-ins for checkout, recompile and package reload — which makes NSO actions testable as well. Building it in-house is what made the migration free: a legacy mode still reads the old payload/expected pairs, so none of the existing tests had to be rewritten. One scenario is one YAML file and one GitLab CI job, run through parallel/matrix against an environment nem has just built.

The case I care about most is replaying a service deployed under version n-1 through a recompile and redeploy under version n. Configuration-level testing has its own value — it shows exactly which configuration changes — but it cannot catch this one: with a broken YANG model, new service instances still deploy perfectly well, while the instances already in production stop being redeployable. That is where you get stuck, and it strikes at what NSO exists for in the first place — managing the lifecycle of network services, not just pushing configuration once, which Ansible already does easily.

Dashboard

A Svelte dashboard that brings merge requests, their Jira tickets and staging releases onto a single page. Preparing a staging release used to take two people a full day, walking every NSO package to check the state of its merge requests and collect the right tags; the dashboard finds the latest tag of each package and commits it to the YAML of the infra-as-code repository, and the same work now takes under five minutes.

A "My tasks" view lists every merge request where you are author, assignee or reviewer next to its Jira ticket — matched through the ticket reference carried by the branch name or the MR title — and lets you change the ticket status without leaving the page, which turned the drift between a merge request and its ticket into something visible rather than something the product owner had to chase.

ZTP

An HTTP server built with FastAPI for the zero-touch provisioning of network equipment, running 10 to 20 devices on a typical working day. It replaced a Flask application that had grown too heavy to maintain and gave no per-device visibility: the rewrite is lighter and adds logs and tracking for each device, so the operations teams can see where any piece of equipment stands between day 0 and day 2 — on a web interface served by the same application, with no separate front end.

Standards

I set the Python baseline every project on the team builds on: uv for dependency management, environments and packaging in place of hand-rolled venv and pip + requirements.txt, with ruff and mypy for code quality.

Languages

Skills