Skip to content
Business Agile
← Work
API · Rail engineering, internal application · 2020

SNCF DGEX Solutions

The back end of a digitisation application, inside a closed perimeter.

Key figures

length of the engagement, autumn 20204 months
lines of the client's code kept on my side0
screenshots published0

In autumn 2020 I worked for DGEX Solutions, the engineering subsidiary of the SNCF group, on the back end of an internal digitisation application. The engagement ran from September to December, alongside my work at SNCF Réseau.

The project in detail

This page is deliberately short, and it is worth saying why. The code I wrote on this engagement lives on the group's internal repositories, behind its network. I hold no copy of it, I will publish no extract of it, and the data the application handles is confidential. A contractor who kept a copy of a client's code on their own machine to feed their portfolio would be doing exactly what a large organisation fears, and that is why confidentiality undertakings exist.

It is also why no page on this site about an SNCF engagement gives a commit count, a volume of lines or a screenshot, while other case studies do. The difference is not an oversight: it comes down to who owns the repository. When the code is mine, or belongs to a client happy for me to discuss it, I give the figures and let them be checked. When it sits behind a group's network, I give the period, the nature of the engagement and nothing more.

What I can describe is the way of working, because that belongs to me. A digitisation application is a flow: documents come in, are split, recognised, filed and made searchable. The back end of such a system carries the data model, the long-running jobs that have to be taken out of the request cycle, and the endpoints the interface consumes. They are the same building blocks as on my other engagements, with one extra constraint: everything has to run inside a closed environment, with no external service called from production. You will notice this page does not even list technologies: a client's technical choices belong to that client, not to my portfolio.

If you are a large organisation wondering what I will say about you after the engagement, the answer is on this page. The client's name, because it is proud of its engineering and it is not a secret. The period, because it is in my invoices. The nature of the work, because it is generic. And nothing else.

What was done

  1. 01

    Back end of an internal digitisation application

  2. 02

    Engagement from September to December 2020

  3. 03

    Code hosted on the group's internal repositories, no copy kept

  4. 04

    Confidential data, no screenshot published

  5. 05

    No repository figures on any SNCF page of this site

Frequently asked questions

What do you publish about an engagement covered by a confidentiality clause?

The client's name if they agree to be mentioned, the period, and the generic nature of the work. Never the code, never the data, never a screenshot. For DGEX Solutions that makes for a short page, and that is the intended result.

Why do some case studies on this site give figures and others not?

It depends on who owns the repository. When the code is mine, or belongs to a client happy for me to discuss it, I give commit counts and measurements that can be checked. When it lives on a group's internal repositories, I give none.

Do you keep a copy of your clients' code after an engagement?

Not on an engagement inside a closed perimeter. The code stays with the client and I keep nothing. That is also why part of my work from past years cannot be shown here.

Other work

A project? Let's talk this week.

A short brief, an answer within 48 hours, a firm estimate after scoping.

Describe my project