 I'm Meryk Dikay. I'm what we call Deputy Director for Innovation and Digital Transformation, that's a big title. And what I'm going to say here is just my view doesn't apply completely to the ministry I'm representing today. So what I'm going to talk is not too much technical today, it's just a journey we are going through. And what's going to happen is I'm going to share what's happening and I'm really happy to get some feedback and suggestions from you guys. You are the one making the technology. I am part of the people who are transforming administration. So we need to mix. So basically, what's the ministry anterior in France? We have two main purpose, it's secure people and goods and making democracy a reality and make it work. So we are running the elections and stuff like that. So I mean, feel free in France, this is the ministry taking care for you and you should not see us when everything is fine. That's the point. We are not very digital. We are many people on the street behind desk and so on and so on. So what's going to happen in France? Why does a little bit of view is we in France decided a couple of years ago as many countries in Europe and the world to go to digital transformation pass. And our approach is what we call a doctrine. A doctrine will be rules. It's we want to go and we have to go cloud first. So regulation says everything in France, new digital project must go to the cloud. Plenty of sort of clouds. And what is a little bit special is we as ministry of interior, we are a cloud provider. So we run on-prem, not only on-prem and we can see and that's what we do. But we like things, we maintain things. So we have very old stuff just close to cloud. So everything which is put and has to run all the time. So we maintain a lot of very vintage technology, nearly all the main frame if you see what I mean. So this is what we have to do is how to address those different ages. People in ministry may have seen in their career about three to four breaking through generation of technology. So we have to think ahead and sometimes we are moving very slow. But our purpose is just to sustain it over the time. So what we do is we invest in the clouds. Currently we have what's on the left, which is legacy IT that everybody knows. And we had the YAS platform for about five to six years, which is only open stack. And it's not CPU, it's core. Sorry, I make a mistake. And we are building a new platform with Red Hat, which is we renew the open stack. So we have a big move currently about thousands of tenants. And we are building something based on Kubernetes. I'm going to show you that later. So we are moving from a philosophy which is we're running for you. Everything is going to be fine. To something which is more close to you run it. If you build it, you're running and you support it. We want to share with the developer the responsibility of the way of making teamwork. We believe it's the target. So how do we do that? How do we think about that? Let's say for people who has worked in very, let's say, ages organizations. Things are very compartmented. Process are difficult to move, I mean to change and so on. And if we just want to make an incremental innovation, maybe in the next century it might be done. So we decide to go to disruptive approach and to offer something what's called for the people who are doing marketing, blue ocean strategy. That means you offer something new. You don't discuss about the detail. You say what you do currently in a month, you can do it in days or even minutes. Would you like it? Generally the answer is I'm going to think maybe. So just to give you the idea. The second thing is there was too much thing to change. Process, technology and so on. So we decided to go to Greenfield. The second thing is we decided because there's part of the ministry which is very linked to open source. We even have a Debian developer in-house. So we decided to go open source. So the first thing is community. But with some vendor support like Red Hat for OCP. So we choose OCP. And then the rest is we also outsource our code. So here is the link. It's a GitHub. So it's in French. But you will find a few, you will find the design documents and you will file also incrementally the code we are doing. So you will see. So that's the way we do it. So what is the product? So the product is, as you understand at the beginning, is we transform the ministry but not only the others. And what we had to offer, what was a real big problem to solve is the pipeline. It's not the running part. It's just the pipeline. How do we do code? How do we maintain the quality of the code? Most of the developer are now from the lockout and the COVID or whatever are working outside. So before our paradigm was you have to be on our house to work and now the paradigm is you may need the people outside of us. So we had to make a bridge between those two, between our secured server and the developer which are outside. So what we did is we just look at the problem and we said, OK, should we do it with one thing as generally proposed? We say, yeah, OK. But then that's when you have to mix between agility, ergonomy, and security. And the developer wants freedom and we want security. So it doesn't match. So everyone wins. But it's always going to be security that wins. So we decided to separate the problem. The developer on his side has his own CI, CD, his own pipeline, everywhere he wants, as soon as we agree on. What we just required is that the developer give us, the developer is the team. Just not only one. The team is just delivering good code without bugs and without CV. And we just don't buy a contract. And then we have in the middle, our pipeline, which is taking from the point of truth the code and the infrastructure of code. We don't trust the developer too much. So we copy the code, check it, rebuild the stuff, do our test and test checking, and so on and so on. And then we put the code, I mean, the container, the container into another point of truth with an infrastructure. And then the deal is the interface is GitOps. So the cluster pooled the code and make it once. And this approach makes everybody comfortable because the developer is on, let's say, an area of liberty, freedom, three. And we manage and we can do audit as much as we want. It can take hours to run. We don't mind. That's not the point. And the other thing is another benefit of this approach. So it's going to be open source, just in case you're interested. The other approach, we don't want everyone to come on our cloud because it's very costly to manage a cloud and to build a cloud. So we want other people to use the benefits of public clouds. So we said trusted clouds because of foreign laws and someone in the morning have talked about that. So that means this approach with GitOps, we already make some tests, which are very, let's say, enjoying, is you can run it everywhere. That's the point. So everywhere on the cloud, we trust. So that's what we are building. So the way we're also building is more on doing it open. So, I mean, to confront something new, to make, let's say, make sure people are there and mainly the developer community, we need to listen to them or to make them on board. So what we've done is we decided to go on Agilatscare. So we're using the safe framework. And what you see here is just a cartoon about one of the PI planning. Or you can see we use the pirate metaphor. So we have a lot of pirates doing things. And this is what we do. So the most of all, this is really the human element, which is key for us. And I see we have to progress here, regarding gender equality. And but this is many a team. And I would like to thank all these teams and every people. They are really highly motivated by the product. They are the one doing the job. So at the end, you can applause them because they are doing very hard work. Where are we today? Am I good in the timing? Yeah, it's okay. So we might take some questions. So we are not yet on production. But we've learned some lessons so far. It's about one year we are doing the journey. The thing is open source was the good idea. Because we never had so much feedback and so much suggestion if we did not use open source. The promise which is ongoing, and you know guys this is happening, is to deploy software in an event like ours. It's about six months to 10 months journey. It's very complicated with security check and whatever. And now, okay, you have to prepare a little bit. But we know we can bring down it to a couple of days. Even hours. And the reality for small application, it's done in minutes. I mean the Argo CIGI when you see the stuff running, it's like okay, it's done. The other thing is it's Kubernetes is really robust. This is our feedback. When it's run, it runs. Okay, it's slow to start. But when it runs, it runs. It's really appreciable when you do that. Okay, let's kiloport. There's no problem if we start. You know it's magical when other people doesn't believe us. And more of all, what we've done in parallel of building the platform, we are transforming some applications. And we are training the people. Because if you don't do the same, I mean everything at the same time you can wait another, it's going to take you some edges. So we train people not to Kubernetes, not to agility. We train them to DevOps. So we took one of what we found was really interesting, training on safe, which is the DevOps, which is not technical. And we put on those sessions, we mix the people between the business people, the tech people. For them to envisage what could be the new experience working with us. In fact, working with the platform. Okay, I'm fine. And then what also, so we were very surprised because at the beginning we thought like, okay, it's going to take some time. Well, nobody's going to follow us and so on and so on. No, no, no, no. It's not happening this way. You get really, really, really fast. People say, I cannot solve this problem anymore. Can you help us? It's really happening. And that's an issue because we were not planning going so fast. So we regulate a little bit who is coming to us. And what we found, we're going to see that on the inside is you need to have a learning path. Really, you need to make sure the people are getting on board at the right speed, but not too fast. Because this is really new paradigm. They don't even imagine that it is possible. I can remember some discussion with people from security. The guy says, what? You can scale everything in your enrolment registry and make a report about what's going on. Yes, we can. So it's simple thing like that. We change their mind. They said, wow, okay. Can you do it regularly? Yes, of course we can. Can we have it before? Yes. Okay, because we know what we have on the premise. The other thing is, this is a new discovery. Every vendor doesn't... Most of the vendor we've worked with doesn't run natively on OpenShift without effort. Just a simple thing about Woodless. Most of the developers just pick something or get whatever and just make it run. Okay, it's running, but it comes to OpenShift. Things are different, which is a good thing. But however, you need to prepare the people and you need to talk to them before. Okay, you can do it fast, but you have to think about those stuff. And then the rest is organic architects. You have to transform your architect people just to make sure that they split the model. And also the main thing is not fully about going to microservices. It's more the organization coupling, which is a nightmare. So if you don't think about your coupling, the organization coupling, I mean, nothing will go at the speed you want. And then that's the main thing I wanted to share with you. So if we're on time, three minutes, we can maybe take a couple of questions. So maybe you can upload the team if you want. Just maybe they can hear or know. They are listening. Guys, this is for you. A couple of questions, maybe. Ladies first. Are all your open stack CPUs moving to OpenShift or is that a separate cluster? It's a separate thing. In fact, we have an OpenStack and an OpenShift. We mix both on OpenShift, on Yes, or OpenShift of BarMetal. We mix. That depends of the application. Hello, my name is Lavent Axel and I'm from Turkey. My question is about your data, your sensitive data. Is there any regulation in your country in order to give you permission to put your sensitive data to the hyperscader or public cloud? Because the main problem is in our country, in the police department or minister of interior, they want to make this... Okay, but they're ready to put their application to the cloud, but they're not ready to put their data to the cloud. So data and the application should be separate within their perspective. And it's also something related about the regulations. So is there any specific security concern that you consider about this transformation? Yeah, good question. Thank you very much. Yes, we do. Let's look at that. On this cloud, I just put the slide you see here, two classifications. In fact, what we call standard or non-protected can go whatever they want as soon as they know how to secure the data, meaning having backups, make sure the data is, I'm sure to say, integrated. Someone can help me? Okay. But for something which is what we call sensible data or sensible use case, it's only on-prem. It's only on-prem and we have separate zones. We don't owe to confidential zones. We don't need them. But what we call restricted, that's main police data and stuff like that. We run the election on those kind of things, so we don't want to put that on the cloud. Is it on show? Maybe one question. We had a light, some suns light a few minutes ago. Thank you so much for that. Thank you.