The only advice I'd give would be to lean hard on finding, maturing, and then advertising end-user champions.
Cross-department / -traditional boundary products are frustratingly difficult to push top-down, as the leader of the space that "owns" the product (i.e. IT) doesn't directly see the value, because they're not the end user (business).
What mostly work for me was being as loud as possible with open-attendence educational events, continually taking meetings from interested areas, and then mentoring developing teams.
The goal is to help them create a killer product using your product, such that (highly-placed leader on their side) talks to (your leader) in glowing terms about your product. And that usually happens because your product helped them get a win that moved an important metric to them.
Hint: Ask them about things they've always wanted to do, but couldn't because it was technically impractical. There's probably at least one diamond in there that would be "easy" with your product.
Hint2: Think more broadly about the kind of thing you're trying to do, and get your team in that area. I've worked under CFOs as often as I've worked under CTOs, because "saving money" is near and dear to the former.
(Adapt as necessary to how French government works. Good luck!)
I tend to think that platform/framework teams within a large orgs should be run as a B2B SAAS, at least with that mindset.
Also, if a platform team isn't run well, it ends up being the first one on the chopping block during layoffs. Uber laid off an entire developer-platform team earlier this year. One casualty was the Screenflow team, a promising product that didn't gain wider adoption due to terrible marketing/evangelism.
What features should you work on next? The things your users are asking for at your touchbases.
There's a time and place for top-down, but it works best when there are few edge cases. Platform work tends to be a normal distribution with the usual number of "Oh. We never thought anyone would want to do that" tails.
Compare the offers from Dropbox, Facebook and Apple.
The kind of person who (a) lives in business problem land & (b) is proficient in programming language design (even guided DSL generation)... doesn't exist. At least not in hireable numbers.
And those that do are buried deep in the guts of consultancies, who can afford to pay them way more than customers can.
It's a shame, because it results in suboptimal software. And suboptimal tooling available to the devs that do work in that space.
The best solution I've seen are products that lower the knowledge barrier of entry (at least for creating a proof of concept) + designing for non-programmers as your primary users.