Hubert Tournier
Transcript (Translated)
This presentation is titled 'Building on the Work of Others' in our program, and marked as 'Opposing the Work of Others'. It's a similar idea, but it's not quite the same thing, so I'll have the opportunity to come back to it. Today, I represent a company, the Musketeers Group, which you certainly know more, or through its main subsidiary, the market, but there are other things I will also tell you a little about.
And then, in this company, I have the opportunity to ultimately handle the organization of the business and the information system. There are several subsidiaries, it's the infrastructure, and I generally oversee the main subsidiary, which is founded on the movement.
The agenda I propose to you is as follows. I will mainly give feedback from experience. I am not a consultant on the island, I don't go to the island during the day, it's not a term I use. I may do it without knowing it, precisely, there are some elements that resemble me, chances to things you know, but it's not a reflex and it's not an end goal for us. So, I will first give you some context elements, because there is no positioning or reaction to solutions if there isn't a clearly defined need beforehand. And so, describing this to you will help you understand why we try to do it. And then, a solution element that interests us, what we could call free software or open source. Personally, I say open code or liberated software, it's a way to avoid a small semantic flaw within the framework of the Internet. In English, there is strong confusion between free (gratis) and free (freedom). I will talk to you later about what we have done, and then in your experience, about what worked and what didn't work. I think it's even more interesting to understand what didn't work well. That's what can possibly serve as... To tell me about many problems for others. And then after, you talk about things we can do in the field of economics, but for once, without saying the trouble of these things in relation to what you want.
So, the Musketeers, just to situate, because you may not know this group, we are not listed on the CAC 40, so you may not see us, but it's a company with 40 billion euros in turnover and over 150,000 employees. So, it's one of the 15 largest French companies, quite simply, even if we are not often talked about, and it's not on most people's radar. What is it? It's a mass retail group, but it's a bit more than that too. It's a group that is one of the major players in the French agri-food industry. And that is noted here at the bottom. We have 64 production units in France. So, it says we produce everything locally. Perhaps you will have a practitioner's reflex regarding the supply chain, and you might think, well, they did that to reduce waste related to transport, etc. In fact, that's not exactly it. In our universe, the discount universe, we try to have low prices. But we don't necessarily need to have the lowest price, because the lowest price can have a detrimental effect on the economy, meaning we might be led to relocate what we produce, what we do to countries with lower labor costs. And it turns out that we have a point of sale in France every 17 kilometers. Our customers are here; we don't have a single point of sale in countries to which we could relocate. So, it is absolutely necessary that the people who work here have a job here, an income to be able to consume in our points of sale as well. So, this is a virtuous circle. In any approach, there comes a time when you perhaps shouldn't push too far because afterward, it becomes counterproductive. So, that's an important element. Now, to talk about IT, we don't have an easy and favorable starting point because we are actually a very large company with many different professions. There are four main professions: food, DIY, automotive centers, catering, but there are also huge support functions. We have a logistics department that employs 10,000 people, and I believe if it were isolated, it would be the third largest in France. We have a kind of real estate activity that manages over 3 million square meters of commercial space. We have banks, insurance companies, security services, in short, everything that can be useful to us within the group. From this point of view, we operate a bit like a Japanese or Korean conglomerate, as you may have known. So, that's not necessarily the most favorable ground for having a lean approach. Then, regarding my point about free software, there is an interesting aspect to mention: we have an approach from the start of sharing value. Free software is about sharing, above all. What the founders of our group wanted to do, and beyond that, because before we had members who were also part of the Leclerc group, and if we remember the founder of the Leclerc group, he was a former seminarian, so he was a man who said that when you have earned your first 50 million francs, you may not need more. And so at that point, you can share the value with others. So, in the group, in the environment that shaped our founding members, there is this idea that at some point, it's useless to have more wealth; it's better to share it with others. That together we are stronger, which is why you have our well-known slogan, 'All united against the high cost of living,' and also this idea that no matter the origin, no matter the education, no matter the background, one can progress, one can have top-level responsibilities, and that's exactly what happens in the group, where among our 3,000 business leaders, you sometimes have people who are former butchers, people who come from the ground up, who didn't go to Sciences Po, who didn't go to ENA, who didn't go to Polytechnique, but who are still at the helm of one of the largest French groups. So, that's a quite interesting example. In the group, we have several maxims. There is one that is interesting, which will probably speak to you. We talk about the right necessary at the right price. What is the right necessary? It's the idea that we are in a world of discount. We are not here to do luxury; it's not L'Oréal. So, we have a service to provide, and the more frills we add, the more it will weigh down and ultimately increase the cost of the service. So, in a way, you see, without talking about lean, we have been in this approach for 45 years. And at the right price, because when we do something and when we have all these subsidiaries working for the group, it is obviously necessary that they be competitive compared to the outside world. If they were out of step, it would be of no interest. So, it is absolutely necessary that IT, for example, be better positioned than any market provider. No, that doesn't make sense. In this very large group, we have an information systems department, which is a group of companies with about 1,000 people.
I have given you some sizing elements of what we do. Here too, we are among the largest French IT departments. Among the interesting and discriminating elements, and I think they are important in relation to the reflections you may have, we have, as I told you, an organization and information systems department. And what matters is the top of this department. It's the organization of the business lines. And that means that within these teams, we have an internal business consulting department that has the ear of the group's top executives, working with them on prospective topics, on monitoring, innovation, working on organization or reorganization plans, working on strategic plans. And why is this important and interesting? Because when you talk about Lean, you talk about Lean Management, when you talk about the impact of the methods you use on the company, there is a prerequisite that may not always be mentioned: you need to have the ear of the leaders. You need proximity, contact, a relationship. To be able to do the rest, and if you don't have all that, nothing will happen. So, here, we have a tool, and we consider that we are indeed well positioned thanks to this tool, which is not quantitatively very important. There are about fifteen to twenty people in this small consulting team. But on the other hand, it allows us to have contact at the highest level in the group to discuss the real issues. And when we talk about IT, we talk about a means among many others. But what really matters is what we do with it, why we use it, and ultimately, having this contact at this level is what creates value. Our context, the starting point, is what?
It's that in mass retail, for quite some time, at least in France, we have been in a rather frenzied price war. We even wonder if it's really a good calculation, because when we talk about creating value, value is somewhat in the eyes of the other. That is, what you can do, which has value for you, but is not perceived by the person you work with or for whom you work, has no value in fact. It's rather over-quality, it's rather unnecessary spending, precisely. And so, is it really smart to put all our efforts into prices and reduce the cost of certain items that cannot be perceived at all by the consumer? In any case, it's not very differentiating since each of the major players in French mass retail tries to do the same thing. So, we try to advocate for a different approach. Nevertheless, in this context, what we are obviously asked for is to reduce costs. And with an audience that would like to have these cost reductions without necessarily making concessions on their level of demand, on the risks they may be led to take, on the quality of what will be done. And so, this will be a rather complicated parameter to manage. Ideally, to satisfy people, we should be able to do more for less. So, here we are perhaps a bit beyond Lean, because in Lean, we say we will try to do better with what we have, but here, we would need to do even better with a little less. Then, there is an important factor: our sector is not yet uberized, but it could very well be. There are already people who have positioned themselves in intermediation between those who have food products or others to distribute and those who have shopping to do. And sometimes, we have people who don't have time to do their shopping and others who have a lot of time but no means. And so, the idea is to connect them. So, services have emerged to somehow bring together those who have errands to run but no time and those who have time but no money. So, we are not immune to this, and in our field of distribution, we actually think that in the coming years, perhaps the next 5 or 10 years, 20% of our activity may end up online. So, this is an important factor; it means we cannot let 20% of the market share slip away; we will have to pay attention to it. When we are in this digital business, we are clearly in a forward-looking approach. We need to look at what is going to happen. Sometimes, you only have weak signals in your daily life. We need to be able to identify all of this, make something of it, and propose actions. When you are not necessarily in these kinds of proposals,
Because people are focused on their daily tasks, they are thinking about their immediate small problems and are not necessarily reflecting on the next 5 or 10 years. And so, that is the purpose of the organization's management and the advisory board I was talking to you about earlier. When you are not necessarily in that mindset, what is going to happen? It means we won't see certain developments coming. And so, people will say to you, 'Ah, now I understand because I see a competitor who has done it.' And so now, obviously, I would like the same thing. Except that since they just did it, we are already late. So, you see, when you start the project, in fact, it should already be finished. And since then, when you announce that it will take... If it's more than three months, you are simply not in the expected timeframe for everyone involved. So, digital technology, perhaps due to this lack of anticipation, is a topic that leads us to truly rethink agility within the company, and we have many requests of this kind.
And then, in this context of reducing expenses and costs, there is something quite surprising: our suppliers, who often like to say they are more our partners, are simply playing a different game than ours, in the opposite direction. While we have to reduce our expenses, they are rather trying to increase them by 20 to 25%. So, we have a bit of trouble understanding each other. We are not exactly traveling in the same direction. So, what behaviors do we observe? Behaviors of rapacity, and that's why I will talk to you about books later, but not to discuss prices. What I will talk to you about is rather freedom, precisely. Because what happens when you have this type of relationship? Eventually, one dominates the other. Now, this may not be obvious to you, but there are theories about the establishment of transactions and interaction costs between companies. The worst relationship you can imagine is the market relationship, where there is no trust and where you ultimately put people in competition from one time to the next. This is exactly what happens in the public sphere, for example. You then have relationships in which you may come to dominate your suppliers, relationships in which it is the suppliers who dominate you. In that case, there is always one party that is not satisfied with what is happening, so these relationships are not sustainable. And what is not sustainable will lead you to seek alternatives, and that has a cost. Time has a cost that is quite significant. And then there is the famous partnership relationship, which is more of an ideal than anything else. for now, because no matter what we say, everyone has their own interests, and they do not always coincide. So, we have an additional demand regarding all this, which is a demand for independence. Where do we come from? We come from a rather industrial IT sector. I told you... Oh, sorry.
Yes, again.
Wait, let's wait a bit for luck.
You can go ahead, but I don't need that to tell the story.
I told you about... Oh, sorry.
Yes, again.
We will wait for the luck.
I'll let you do it, but I don't need that to tell you the story. We come from a rather industrial IT sector. I told you about a logistics operation that employs 10,000 people. What is important for us is not to miss delivery rounds, orders, optimizations. And all this means that with the diversity of sales outlets we have, you saw that we have more than 3,500 in France. Okay, is it back?
Thank you. Yes, thank you.
He doesn't want to.
Anyway, I'm here to tell you things, not to read pages. So, what matters is especially the following: this activity means we must not fail. 3,500 sales outlets, I don't have an IT specialist at each of these sales outlets. This means that if I have deployed something that doesn't work and requires a physical intervention at each site, just to give you an idea of the scale, it costs me 4 million euros to send someone to each sales outlet, even if it's just for half a day. So, this means we will have to reinforce testing and all that sort of thing. Now, the stories about open-source software. I gave you my little personal expressions on the subject.
What must be seen is that it is truly a means, not an end. In the world of open-source software, there are not... many people for whom it is an end in itself, meaning they look at the solution before looking at the why, why we do this. You have many people who are, I could even say, open-source fundamentalists, so it's always pleasant to discuss with them because we don't have rational discussions, precisely. And so, those are the people we don't seek to have, but fortunately, there are others.
So, as I said earlier, it is one of the means to do more with me, because often, I have proprietary solutions that actually don't bring me much compared to what can exist in this open-source world. It's even worse than that; they bring things I don't need. And once again, what I don't need is somewhere between added value and over-quality. it is something that may cost me more. If I have software with many more functions, it means it is more complex, it may be perceived as such by my users, and people may ask for more training. So, you see, even the features that are not always used, that are not often used, can end up costing me more. So, what is important, as I said, is that we are not only here for the price. Let's not hide it, it is still interesting to have software that doesn't cost much. It is more interesting to have software where you don't pay per deployment and you might pay for support, perhaps more expensively, but that's not a problem at all. You might pay people who are more skilled to develop it, but that's not a problem at all, as long as you are not paying for a fictitious service called maintenance, which we pay for with many software programs, where in fact there is zero service rendered each year, but for a cost that you repay, which is around 20-25% each year. A fictitious service called maintenance, which we pay for with many software programs, where in fact there is zero service rendered each year, but for a cost that you repay, which is around 20-25% each year. So, that interests us, and precisely, we don't disdain anything in these areas, because as soon as we are in a relationship of dependency with a major supplier, what will they do? Every year, they will come to ask us for more money. So, you see, Open-source, in its dimension of being free, which is not always the case, is not an end in itself, but at the same time, what interests us is knowing that it will not increase excessively and unilaterally every year. Our primary motivation is freedom. The reason we have internalized many activities in our group is precisely to have all the necessary means to do what we need to do. So, it's the same here. Having software that is critical to our operations and depending on a third party who will dictate their conditions and laws does not please us much. And so, in this area, even if we have to work with communities or others, we are at least free in one thing: if we need to make developments or modifications to software, we can do it, we can pay someone to do it.
Our secondary motivation is agility, indeed, because we need to do things faster. That is not the only meaning of agility; I will come back to it a little later. But when we do things faster, we also do them more cheaply. So, that is interesting. So, there are many software programs available. There is what we call at our place 'good enough,' we come back once again to the bare necessities, meaning many people offer us a software-as-a-service solution, as you have heard about in the field of cloud computing, a solution called on-premise, which we buy and operate on our servers, and sometimes a so-called community solution. In fact, it is not really a community solution; it is managed by a company, and generally, the community solution has fewer features, the on-premise solution has a bit more, and the software-as-a-service solution has all possible features. And in fact, often, the features... included in the so-called community solution are sufficient for us. There are even already too many. And there is something interesting here, which I called 'undressable,' meaning one of the modifications we may be led to make to software is paradoxically to remove from the interfaces all the things that could create too much complexity for our users. The features we don't need, we don't remove from the code, because often there is a separation between the code and the interface, we just remove them from the interface. And that interests us a lot, indeed, to be able to simplify things for our users. Then, we have ready-to-use solutions, and we have progressed, though I don't know if others talked to you about it yesterday or will talk to you about it today. We have a new quantum leap in the efficiency of what we can do in IT. A few years ago, we moved from physical to virtual, and now we can move from virtual to cloud, what does that mean? It means we are not obliged to maintain all the environments we traditionally have for an application at any given time; we can allow ourselves to instantiate them only when we need them. For example, a testing environment, I only need it when there are testing phases. Outside of those times, I don't need it. And at the limit, even a production environment, I need it if it is used interactively during the day. If at night, I don't run batch processes, if we are no longer in that world, I don't need it at night. I might be able to free up the machines to recycle them for other things. For this, a very high level of automation is required. Everything must be controlled by launch commands. And that becomes interesting. The only problem is that I don't know how to do this with most proprietary software. Why? Because of licensing reasons. If you look at the licensing terms of the software for which we rather buy the right to use, most of the time, what do they tell you? If you read the fine print, you notice that you cannot even... use it in a virtualization context. If you start saying, I will place it on a server with capacity A, for a population that initially is nominal, and with a power that is determined, but then you think, after all, it was virtualized, I add more power, I add more memory, I add more CPU, I add more of everything. One day you think, I don't have enough, I change it to another machine. Another day you think, now if I were inside the company, and I sent all that outside, so I am right in the middle of the Internet, and then one day you think, after all, the people who operate my application are no longer the populations I clearly identified within the company, it is potentially anyone on the Internet. In the licensing contracts of almost all software, this is practically impossible. So, precisely, if we do this to go faster, we are not here saying we will go negotiate with the legal department of this or that publisher, which will take three weeks, a month at least, to see if we simply have the right to do what we want to do. Therefore, somewhere, this agility made possible by cloud computing techniques that we can use either internally or externally is completely compromised as soon as we use proprietary software. So, this has pushed us to go even further in the field of open-source. What did I put in there? So, a solution designed for automation, I illustrated that well for you. And ultimately, I mentioned people who are more open-minded, more technically skilled, more versatile. Not all of them, because as I said earlier, we also have people in front of us who are sometimes the worst fundamentalists one can imagine on the subject. But still, we have people who have gotten into the habit, given a situation, of looking to see if there are not already ready-made solutions. And that, the curiosity to see if there is something, is already extremely valuable. People who are capable of delving into someone else's code, possibly not necessarily to modify it, but enough to at least read the documentation, that is interesting. Eventually, knowing how to modify it is the most important, but you don't always have that kind of population. All of this is quite interesting. And in a way, we have individuals who are, as I noted, more skilled, more versatile, more adventurous—I could put it that way. And in a context where you have to do more with less, beyond the software, the human aspect is absolutely critical, it is truly predominant; it's more the people who will make the difference than the software. There's a little Chinese proverb that says, 'When the wise man points at the moon, the fool looks at the finger.' But that's kind of it. The software knows well, but what really matters is the intellectual agility of the people who are able to manipulate that software.
So, it happens that I have the opportunity—I don’t say this lightly—but I am someone who has remained quite technical, since I still do development, even if I have other responsibilities today. I do this at night, of course; no one asks me to do it during the day. I do this for my children, to have fun, to keep my skills sharp. Because I also think that keeping a technical side is absolutely essential in our field. If we don’t have this technical dimension, we can’t properly manage this kind of thing. So I think it’s actually an advantage and a distinguishing factor. It turns out that when I started using free software, it was around 88 or 89, so that’s been about 27 years now, so I have a little perspective on the subject. At that time, Linux, for example, which for many is synonymous with free software, simply did not exist. It only appeared in 91; there were other things before that. And at that time, the really interesting thing was the Unix system. In the Unix system, That’s what inspired the title of this talk. There’s a book I bought in 89, which was a system manual. And there’s this maxim that is quite important and has guided me throughout these years: build on the work of others. And what does that mean? It means that even before we talked about free software in a somewhat generic way, The idea of Lean, in a way, is to say that we’re not going to reinvent the wheel, we’re not going to rebuild and redo what already exists and what is potentially interesting. And there’s another idea too: when we do this kind of thing, we’re not inventing overly complex systems. That is, if we have the logic of filtering, which is at the very heart of the functioning and philosophy of the Unix system, it’s to say, I’ll do a small part that works well with what’s below it and that will potentially be usable for what’s above it. So we build by accretion things that are designed for their versatility. And that’s really something interesting. What’s said in this manual is that, in a way, we’re just joining a culture that was there since the late 60s. So you see that regarding things that later became the book, there was a whole foundation that led us there and was a bit older. In the book, you have people, the famous activists I mentioned earlier, who talk about copyleft in reaction to copyright. But there’s another philosophy, one that comes more from the BSD world, which is the world I come from. BSD was another family of Unix that was created at the University of California, Berkeley. And in the BSD community, we talk more about the copy-center philosophy. Basically, we made something, we think it’s not bad, well, it’s there, if you need it, you take it. If you have a problem, don’t come bother us, but we share, and it’s there to be used. If you want to appropriate it, if you even want to sell it, frankly, we don’t care. We might even be happy to see that the software we made or the boot code we wrote will be recycled in another software. That’s why I talk about liberated software when we talk about free software, to clear up the semantic confusion. There’s indeed the idea that when you’ve made something free, it remains free. Here, it doesn’t necessarily remain free, but as long as you continue to distribute your software and it’s easily accessible, modifiable by everyone, in a way it’s even freer than free.
That’s one way of looking at it. So, on that note, since it’s an element of the solution that interests us, how did it go in our company? Well, we started in 2009. In 2009, we had a number of problems; we were already too slow and too expensive, as our internal clients were already telling us. And at that time, I read in the press about the advent of something new, the famous cloud computing. So I thought, that seems interesting.
And what happened at that moment? I realized that what was written in the articles didn’t exist. At the time I’m talking about, there were about two or three open-source projects starting to emerge in the cloud domain, none of which, by the way, have survived to this day. All those that were around at the time have disappeared. And besides, there wasn’t even a commercial solution. So we were disappointed because we had understood that it was a solution to our problem, but there was nothing to do, nothing to buy. And that’s when we realized that it wasn’t necessarily that complicated to do. So we defined our problem, I think it was around March-April 2009. We took advantage of the holidays to develop it, and by August 2009, it was operational. So indeed, it wasn’t that complicated to do. Precisely, when you’re in the philosophy of building on the work of others, thinking that virtualizers exist, the glue needed to manage a cloud system is ultimately what needs to be developed, which is missing, and it’s not that complex to do. So we made a small bet; we tried to say, we’re going to release what we’ve done as open source, since it seemed interesting. We were happy, even proud, I can say. But there was also a small failure because just putting code out there doesn’t mean you’ll aggregate and create a community around that code. So we learned that the hard way. And a few years later, although our solution remained, I think even today it has advantages that can be interesting compared to many market offerings. I think we have a concept; we went quite far.
In any case, it remained the case for several years, for 3-4 years, when the publishers, the big publishers like IBM, Novell, or others, came to see us, they told us what they were offering, and we said, 'Oh, that’s good, but that’s the state of reflection we had two years ago.' Now, we’ve moved on. So when you have something that meets our needs, we might buy it, but for now, you’re not on target. Well, all of that is fine, but we’re not in a position to make decisions for publishers, and we’re not meant to maintain software. So when we saw a more mature offering arrive, we switched to it. We continued in our logic of sharing by recycling the information, knowledge, and experience we had accumulated in other projects. So one of these projects was Compatible One, a project that was funded with public funds. In this story, starting in 2009, we thought somewhere... It’s interesting in the book; indeed, there’s software, there are people, but if it’s about retrieving source code, compiling it, installing it on a machine, tuning it, optimizing it, securing it, that still takes quite a bit of effort, and that’s a bit of a deterrent for many people. And so something interesting was already emerging at that time: there were several services like Bitnami, Turnkey Linux, or others, which were ultimately pre-packaged virtual machines with open-source software. What was the idea? It was to say, you could have pre-packaged software, ready to use, a bit like the apps on your mobile phone. You go to a store, download a VM, use it natively, use it virtually, or use it on a cloud, either yours or someone else’s, and that allows you to have the application right away. So it allows you to start quickly. So that was interesting; we did it for a while because we didn’t do cloud for the sake of doing cloud; that’s not the point. What we did was rather serve business needs that weren’t necessarily being met before—short-term needs, collaborative needs, all sorts of needs. And we did it by finding a number of software solutions that met our needs quite well, modifying them, and trying to return these modifications to the different communities. On this matter of returning our modifications to the communities, companies clearly have an interest. Once they’ve modified something, they don’t necessarily have an interest in maintaining it. And so if they can give it so that someone injects it into their codebase and then maintains it, that’s even better. Except that it doesn’t always work that way because some e-lib or open-source software is actually offered by commercial companies, and sometimes what you’re going to... return to them will clash with the commercial policy they’ve proposed. For example, we used a virtualization software at the time called VirtualBox, which is still called that, by the way, which is very interesting, a software that was originally made for servers, but whose last two owners have marketed it exclusively for workstations. collaborative needs, needs for a lot of things. And we did it by finding a number of software programs that met our needs quite well by modifying them and trying to return these modifications to the different communities. Regarding this matter of returning our modifications to the communities, it is clearly in companies' interest. Once they have modified something, they do not necessarily have an interest in maintaining it. And so, if we can give it so that someone injects it into their codebase and then maintains it, that's even better. Except that it doesn't always work that way, because some free or open-source software is actually offered by commercial companies, and sometimes what you return to them will clash with the commercial policy they have proposed. For example, we used a virtualization software at the time called VirtualBox, which is still called that by the way, which is very interesting, a software that was originally made for servers, but whose last two owners have marketed it exclusively for workstations. Except that all the interesting server functionalities are still there, if you take the trouble to read the documentation and look at the code. So when you put the functionalities back into the common pot that allow it to be used as a server virtualization system with all the advantages of VMware, the publisher thinks, in my application portfolio, I have other things, other offers that correspond to this component, and I will not incorporate into the freely available source code things that will compete with my own offers. So you see, the contribution or the return of contributions we can make is not always accepted. We quickly encountered a fairly significant problem, which is that proprietary software had a strong point for our teams, which is that there was someone to blame in case of a problem. When it doesn't work, there is a publisher and they are responsible. And when you have community software, it's quite difficult to say, well yes, it's these people I don't pay, they are responsible for this, they must commit to fixing it. No, they are not going to do it, of course. So that doesn't work. To overcome the reluctance of many of our people, particularly in operations and exploitation teams, what we ultimately found was to set up a support contract for these different software programs. We made a list of what we had, we said, here, the world has all this. Here are the things we could have. And here are the procedures we define to say what we would do if we ever wanted to add something. What did this allow? It allowed us to ensure that people no longer think, 'Hmm, if there's a problem, they'll say it's me.' There is someone whose job it will be, who will be paid to investigate, to possibly make modifications and return them to the community. Okay, maybe it will already belong to them. So that was an important point, but it did not resolve the issue of the technical skills of our teams. Because if you do it without internal expertise, it doesn't really work. We actually had, a little later in 2013, a DevOps-type project. I think that is also part of the conferences you have during these two days. To try to bring our development and operations teams closer together, to have a bit more agility, And there, we again encountered an issue of maturity and competence regarding these so-called open-source or free tools. Why? Simply because when you don't know how to do it, ultimately, you depend on someone else, and then you go at the speed of that someone else or the contract you have arranged to do it. So it didn't work very well. So to counter that, we had another parallel approach. We had a team where we had people who had a bit more of that profile. And so, even if it wasn't them who were tasked with doing our DevOps project, we asked them to look into how to do it.
And we used them a bit like goads, actually. So they did it a bit in the way we had done a few years earlier with our cloud management solution. In just a few months, they managed to do quite interesting things that went much further than what the team tasked with doing it had done in a much longer timeframe. And as a result, this team, which was seen by us as a lab, recently, what we did was transform it into a mainstream team. That is, we said, OK, they won. Their method is now the method for the entire company. So it was experimented in a small corner, it proved its worth. We saw that it actually worked because we had the right profiles of people. And now it's the general method, the goal for these individuals who were at the helm in this small corner is to pull everyone else toward what we found to be good to do. We also needed to ensure that technical architecture decisions were not made solely within production or development services. And so, to bring all the stakeholders around the same table to ultimately discuss what our needs and constraints are. And based on that, we will make choices. And these choices, then, we will engrave in documents that will be somewhat like the law to avoid having the famous variability that you sometimes fight against in the field. That is, if everyone chooses solutions based on their personal preferences, it's generally not great. So we asked ourselves a number of questions. When we were able, we said, for this type of problem, the solution is this one, there is only one. When we were not able, we were able to say, however, in such and such cases, in the general case, it's this solution. In such an exceptional case, it's that one. And so that allowed us to also circumscribe certain solutions.
This led us to make choices, to go even further perhaps in the field of open source, choices like Postgres instead of Oracle, Oracle in some cases, to choose frameworks and tools, methods that were rather open, like VASP for security, I don't know if that means anything to you, but it's something very interesting to look at, to choose servlet engines over commercial products, where precisely... You might say to me, these are not comparable products, they don't do the same thing. Yes, but precisely, we weren't using the additional functionalities of these software programs. And what we were doing, what existed in the open-source versions of these software programs, was enough for us. So then, it was about saying, new projects will all be done with these tools that may be simpler, but at least we use their functionalities overall. And there, we are entering an approach that goes a bit further now. We are actually revisiting our various installed applications to say, now, we will make a voluntary effort to change the software, to bring them to our standard. Obviously, this has an initial cost, but afterward, we have clear gains every following year.
The team I told you about earlier, they invented something, they called it Modern Software. Everyone comes up with little names for... their projects, what is it? It's a platform for integration, deployment, supervision, and continuous production. So in this, indeed, it uses these cloud technologies. The ultimate goal is to be able to say, I automatically grab an available virtual machine, I automatically install it, I automatically deploy the software on it, I automatically run test suites on it. If there is ever the slightest problem, I can do a backtrack in the other direction to free up resources, say it didn't work, alert the right people. And we still kept a little button in the middle to say... Between the final test that tells us everything is working well, it's nominal, it's perfect, etc. And we really review it in production, there is only one button to press, we chose to have that, but we could have done without it. And so there, you have the recommendation, the goal is automation at all costs, and the goal is to avoid redoing tasks that have no added value. What did I have before that? I had people who spent their lives reinstalling systems, reconfiguring them, optimizing them, securing them. Sometimes they forgot things, by the way, so when there is a hole in their game, especially in security, it's a bit painful. So there, you tell yourself, we do it well once, we go all out, we do it industrially, meaning that we need to put the right skills, the right brainpower, to have thought of everything, to have thought of reusability, we do it once, and afterward, it's something we put in a software cabinet, and when we need it, we automatically instantiate it in our famous cloud.
So in the commandments, you see, there are quite a few things. There, you will automate your tests, you will not configure manually, you will no longer create machines manually, you will not intervene to deliver. You will have metrics for your machines, you will supervise. That's the idea of... It should not be done by someone else. It's 'it's your own top foot,' as the Anglo-Saxons say. Do the thing, you live with it. If it's done poorly, you're the one who picks up the pieces. etc. So that works quite well, and as a result, what we did, indeed, the ultimate step in 2015, was the merger of the different teams, and this little method, which was the artisanal method in a corner, became the mainstream method. We don't do it for everything. In IT, in the grand theories of information system organization, people are currently talking about bimodal IT. They even talk about trimodal. We always have our industrial IT where we need to ensure reliability. And that one, we don't handle it in this mode. We have digital IT, which is a bit of the everyday stuff we do, which we handle in this mode. It still aims to cover a lot of things. This is not anecdotal. And after that, there is something our professions call test and learn, which is really experimental. We don’t necessarily expect an operational result. And we can use this type of technique; it’s obviously cheaper and faster to achieve, but it’s not necessarily the norm. There you go, on this part, that’s all I wanted to tell you, but it has been a valuable tool, and you see, my main message is essentially to say that ultimately, what matters is not so much the software, it’s once again the mindset of the people, it’s the human factor, it’s what people have in their heads to move forward. Lean, as I told you earlier, we are not Lean advocates—I am not—though there are some in my teams, like Stéphane Vauger-Vaudat here, who is one of my long-time colleagues and is much more interested in all of that. As for me, if I see interesting things, I will try to adopt them, but I don’t think in terms of IM. It turns out that some of the things we do resemble Lean afterward, and that’s perhaps what I’m going to tell you about. So now, we’re going to move on to more aspects of IT function organization.
So, I retained three main ideas from the line. I retained the pursuit of performance, I retained continuous improvement, I retained the fight against waste. So I will try to illustrate these three ideas.
The people I have in front of me are not IT professionals, and so for them, there is a triad that everyone knows: cost, quality, and time. They would like to have all three. So what we tell them is, It’s sometimes possible, contrary to what is written, it’s sometimes possible, but most often, you can have two out of three. And when someone tells me, well, we want something super fast and super cheap, generally, I come in and say, well, in that case, we’re going to work on the requirements. You’re not going to ask me to make the Rolls-Royce right away. We’ll start with the simple thing that meets the essential part of your need, and if that works well and you really use it, maybe we’ll add to it, we’ll do the next part, and so on. I could give you the slides if you need them. There’s no problem. Then, in many places, there’s a tendency to see the information system as a cost.
Is it a cost? Personally, I obviously see it more as an investment. But on the condition that it is truly treated as an investment. If it’s just about spending money to do anything anyhow, then it’s a cost, and I agree with people on that. But if it’s thought out, studied, and justified as something that will create value, then yes, it’s worthwhile. So for that, we try to do what we call in jargon 'screenings,' elsewhere it would be called a business case. We’ve tried many methods; historically, we’ve proposed at least 3 or 4 different ones since 2006. Because people experience it as a constraint. What I need to tell you is that you might imagine that in companies, people are rational. And that somehow they all genuinely aim to create the maximum value for the company. If you believe that, I’m sorry, but that’s not reality. You have people who may think first of their personal interest and who will say, 'This project will look good on my CV if I do it.'
Afterward, if it doesn’t work, in any case, in 3-4 years, I might not be here anymore. I will have leveraged it to get my next position, etc. That happens quite often, in fact. So, very often, the people who had you do a project telling you 'we’re going to gain amazing things,' etc., three years later, when nothing has been gained or what was planned hasn’t been achieved, they’re no longer there, and afterward, you’re left with the project. So that happens quite often. So, the goal for us is to say that we need to work upstream of projects to try to identify the value we’re going to create. We need to be certain of what we’re doing; we need to justify it thoroughly. And generally, the value is much more important than the cost, so we shouldn’t dwell on it. The cost is important, but it’s 10% of the problem. And 90% of what’s important is the creation of value. And afterward, we need to measure that value creation. And then, no one is left either, because that means potentially putting your sponsors in an awkward position, as we can expose the fact that what they sold didn’t happen.
I told you earlier about my story regarding the difference between the lowest price and the right price. You shouldn’t necessarily look for the lowest price, because then you’ll put out of business the people you need, whether they’re your employees or the companies you work with. So you also need to know when to stop.
Now, I’m putting this here for my bosses—I don’t know if it’s readable—but there’s always the possibility of doing it cheaper in... heard, there’s always the possibility of doing it cheaper. Always. But not necessarily for the same thing. So here, you have a man who has a small Pegasus drawing, and he gets a horse tattoo, and that’s it. The drawing a 6-year-old child could do on his back. So indeed, being able to show that what the cheaper option offers is not necessarily the same thing is quite important. And to do that, you need to be able to discuss it. So the relationship I was talking about earlier, at the right level with the right contacts, is the way to get the message across, and afterward, you need to be able to explain it, and we’ll see how.
What we do is regularly benchmark against the outside. And what we often do is put ourselves in competition. That is, in the same file, we’ll say, here’s the proposal we made with our own teams. And on that, we’ll take the market leader, we’ll take an integrator, and we’ll look at it. What’s the point of doing that? You’ll tell me, we’re shooting ourselves in the foot. No, it’s interesting because... Typically, I have people who come to me and say, hey, to set up an e-commerce site, we can do it in 5 months. I say yes, maybe a small company, but a company like ours, with an IT system as complex as ours, where an e-commerce site will need to be connected to literally dozens, really dozens of third-party applications, it won’t necessarily be done that quickly. And so, having an external third party come and tell you, 'At my place, I cover, let’s say, 85% of your need, it will take me 14 months to do it,' helps put some sense into people who understand a little that it actually takes time to do things. That doesn’t mean everything has to be done in a monolithic way; again, we can deliver things quite quickly and then complete and improve them as we go along. That’s really the idea to keep in mind as well. There’s also an important point, which is that, I try to show people that starting faster costs more. Why? Because often, I have teams, obviously, in limited numbers. Internal staff cost less than external ones, I don’t know if you know that, but there’s an operational reality behind it. The cost difference averages around 200 euros, generally. On average. So, people who want to start quickly, I tell them, if I do it, that means I won’t wait for my guys to free up from the projects they’re on, so I’ll take external people to do the job, and therefore, it will cost you 200 euros more. So if you want to start quickly, there’s a premium to pay for that agility. Otherwise, you wait. And you see, once again, we come back to this cost-quality-time triad, working on the requirements—if you want it to go fast, it has a cost. It’s not free.
People talk to me about agility, and agility has always bothered me as a term because it’s really a polysemous term that covers many different things. So, I’ve listed several meanings of the term here. Behind agility, people often mean responsiveness, that is, the ability to start quickly. Often, they also understand speed, the ability to finish more quickly.
And just to talk a little about this point, the agile approaches that exist, like Scrum or others, are not necessarily faster. Sometimes, it takes the same amount of time, or even a little more, but afterward, we do things better and we come back to them less often. So in a way, in the perception of a business, it’s not necessarily the speed at which we deliver the first thing or the complete thing that matters. It can be other factors. Why do we know that? We segment it like this because it’s not the same type of solution. If I want to be able to start a project quickly, that means I might have what we would call some slack, or 'slack' in English. That is, I’ll have some in reserve, and that will allow me to start more quickly. So you see, the types of solutions are different behind each of these points. To go fast, there are other types of solutions. And afterward, of course, if we could capitalize, meaning the first one who goes through it, okay, it’s long for them, but the next one, at least, it will go much faster—that’s not bad. But those aren’t the most important points. The next point is really about alignment—doing the right things. Now, I’ve mentioned here the big bad word of digital consumerism, but in digital, there are so many trends that people sometimes want things without any reflection on what use it has, what it will serve, and often without any measurement. That's something I've seen often. We spend millions on advertising, but we don't look at what the concrete contribution of that thing is.
So, very often, there are topics for which we shouldn't even create a software application. We would be better off, as they say in eastern France, creating an organizational solution instead. We take 10 interns, put them side by side for two months, they get the job done for us, and it's better than creating an application. So we tend to somewhat forget manual alternatives. We should look at the existence of similar solutions, and in a group like ours, we have hundreds, maybe thousands of applications, so sometimes people are simply not aware that others are already doing roughly the same thing. Sometimes, it's not at the application level, it's at the function level of the application. How many applications, in the landscape that each of you can know at your level, have a search function? Couldn't this function, have been isolated to be shared across all applications? How many applications have an identification-authentication function? Couldn't we have isolated it to make it common so that it becomes a shared component everywhere? Which, by the way, would have a beneficial effect because your consumers, your clients, somewhere it automatically gives them a kind of silent signal when it's the same identification-authentication component managing things. There are quite a few things that can also have indirect benefits. But for that, you need to reflect at the function level within the application. And then, this idea of starting small. All of that is not bad. Indeed, it allows you to do just what's necessary, but it's still not enough.
And there is a typology of things you must not miss: if you are at the foot of the demand, you are already late anyway. So how can you know that demands will arrive long before they do? And we come back to my earlier story about the management consulting, being in a permanent relationship with your clients, the business units, hearing them talk about their business projects, and you thinking, 'Ah, I can derive this, translate it, and maybe propose something that goes even further,' That allows you to be the one who proposes the project rather than the one who endures the project. So that is really important.
It also allows you to think about the evolution of your information system, which is an asset with a certain value, by saying to yourself, 'Here are all the things I will have to change in the coming years.' We manage to do this exercise, we do it with a 6-year horizon, in advance, long-term, and it at least gives people time to reflect and to... Those who think that budget-wise, they will have to allocate this or that at this or that time. We will arrive well before she does. And we come back to my earlier point about the board's direction. Being in a permanent relationship with your sponsors, the business units, hearing them talk about their business projects, and you thinking, here, I will break this down, I will translate it, and I might even propose something that goes even further. This allows you to be the one who proposes the project rather than the one who endures it. So that is really important.
It also allows you to think about the evolution of your information system, which is an asset with a certain value, by saying to yourself, here are all the things I will need to change in the coming years. We manage to do this exercise; we do it with a 6-year horizon, in advance, long-term, and it at least gives people time to reflect and to... Who think that budget-wise, they will have to allocate this or that at this or that time.
Quality, which I could translate differently, because so far I have mainly talked about over-quality, There is truly a completely economic relationship with quality. And most of the time, we are in economic destruction. When we do too much quality, stories of total quality, for example, to me that is a chromosomal aberration, It makes no sense. Yes, I am almost done. I am within the time limit, thank you. It does not make much sense. Why? Because quality that is not visible is just an extra cost. So earlier I said that value is value in the eyes of the other. For you, there are certainly many things in what you do that have value, except that if no one knows about it, in fact, your product, your solution is not purchased for that. And people will just tell you, if you did it and others did not, if you were in competition, if you were competing with others, the others potentially have a value proposition that will be less costly because they did not address those points. So either it truly has value and you market it, you highlight it, you explain it and you make people realize the value it has, or you do not do it at all.
Then, there is another factor that is rather negative, that is risk management. And it is a quite powerful tool. We consider that our role in an IT department is to identify these risks, because we are still professionals in the sector, to analyze them, formalize them, and submit them for decision to the right people. We propose options and we do not propose a binary choice. That is to say, if you come saying, here, either we do nothing, or we do what I told you, that is not great. So the idea is rather to have several scenarios, each with their advantages and disadvantages. That is rather what needs to be shown. That is not what happens most of the time. If I come back to the usual, to daily life in information systems and in IT departments, just take for example security in terms of availability, how many times are the operations IT staff who decide on the means to implement instead of the business units?
Well, almost all the time actually. Well, we must avoid maximalist approaches, there is something you may not be aware of, but we can apply it in the field of information systems, it is called value analysis. What is value analysis? It is a reflection on the functions provided by an object, for example, software. For example, take a water bottle, how much plastic do you put in the cap? You need to think about the functions of a cap. What is a cap? It must ensure watertightness, but it must also ensure a certain grip, a certain ability to screw and unscrew. So those are some of the functions. And then, you need to ask yourself, in the end, with regard to the functions, did I do the bare minimum or did I do too much? This approach, which we traditionally apply in our agro-industrial processes, can also be applied to the information system. And then the last thing is that you have people in front of you who are ultimately the decision-makers anyway because they have the money. And that has also changed in recent years. IT departments used to have the business units' money and, in a way, they tried to use it in the best possible way. That is no longer the case today. It is the business units that have their own money. Either they spend it with you. And if you are not ready, not available, or whatever, they will spend it with someone else.
So we must try to make them responsible, to help them progress. There are two approaches here. Earlier I told you that it was interesting to compare ourselves to the outside. For that, we must really be able to compare ourselves. What is the approach? It is to say... I will have people who will challenge us on the cost of what we do. And for that, I need to have an offer similar to theirs. The offer, let's say, ultra low-cost, minimalist. I need to be able to align with it as well. And then, I will start from this offer when I discuss with people who want the price, to discuss what they want to have. Let's say, hey, don't you think that in your context, function X would be interesting? They say, yes, yes, that's interesting. I say, okay, if I add this function, it will cost this much. Don't you think function X would be interesting? Oh, yes, yes, that's interesting. If I add it, it will cost this much. That is what I call packaging. I start with something ultra simple and I add compartments, each with a cost. And that is how I make people perceive, ultimately, the value of what we create. Conversely, I also have people who want security, but sometimes they tell me it is too expensive. So the idea here is to undress. We go the other way, we say, we thought for you, in your context, we believe this is what needs to be done. Now, if you find it too expensive, we can remove this, it transfers such risk back to you, but it also removes that part of the cost. And you see, whether we go one way or the other, it helps to increase the maturity of the person we have in front of us. That is quite important. For that, obviously, you need to have at least two offers. The ideal offer and the low-cost offer. And we do not always have two offers in a decision. So we need to practice building that.
I am almost done, I am moving on to continuous improvement. We have implemented an internal audit at our place. When we talk about continuous improvement, there will necessarily be a starting point. And possibly, we will climb a slope, we will notch it, we will improve things. So, we need a baseline. How do we create the baseline? We chose to have our different managers work on analyzing their strengths and weaknesses. We would like not to... eliminate the strengths, if possible. But on the other hand, it is useful to know the weaknesses. In the exercise, there was also something that interested us, which is that we asked people to tell us what the weaknesses were in their own department and not in others'. Because when you ask that question, people always talk about what is wrong with others, but never about what is wrong with themselves. It is what is wrong with you. And so the question that arises is... ultimately, have you not been in the function for so long that today you no longer even see the main problem? So that is interesting. Or sometimes it is even worse, people see the problem very well but they do not report it to you. And so that was the first thing, you work, you tell us in your own department what is wrong, what is going well, what needs to be preserved. And we have set up a multi-year internal audit with a plan where everyone takes their turn. So now we are determining the rhythms to see if it's every year and a half that everyone takes their turn or every three years, well, we're trying to do it that way. And so the goal is to have an external perspective, obviously, to make these optimizations ourselves—that is, to identify what isn't working and propose and improve it without anyone else from the outside having to tell us, and at the same time, that's where we'll see if when the guy told us the three main problems at his place are this one, that one, and that one, did he miss the real biggest problem? At the same time, this baseline we talked about is what determined the order in which we addressed the audit plan—where we started. Next, we need to do something that isn't necessarily obvious, but I saw that there are other conferences this afternoon that will discuss it. Everything I've told you, you've understood that it's a company-wide approach, that it doesn't rely on just one person, it relies on a collective, a group of art. individual. And for it to work, the company culture needs to change. In France, we're used to company cultures that are completely top-down, hierarchical. There's a guy at the top, he says something, and there are people at the bottom who do it, more or less, by the way, and there are still others below who continue to execute while doing it, and ultimately, there's a bit of loss at every level, so less and less gets done. That's what I call the 1-1. As soon as they dilute over time. The goal is to say that the situations we face shouldn't be reduced too simplistically—they're multifactorial, they're complex, and because they're complex, we need everyone's intelligence to handle them. And what needs to be done so that people unleash their creativity? Because they won't do it spontaneously. When you come from a hierarchical culture, what people do is think that those who propose ideas, those who innovate, those who try things, sometimes, are the first to be sanctioned. So somewhere, you have to tell them no, you have value too, your ideas are interesting, dare to share them, propose them, etc. And it's even your responsibility. That's not necessarily what happens. There are many people who have the title of director and don't direct anything, for example. So we need to put those people back into a logic of proposing ideas, which no longer exists in many companies. So with our managers, we worked all together—we have about 150 managers in the IT department. To try to encourage this individual initiative and bet on this collective intelligence, we went through a small exercise, which was writing a managerial charter to simply affirm what we wanted to do and for each person to be an actor in it.
So I think this also relates to one of the Lean issues. I don't think it's expressed that way in Lean, but there's a waste that's really terrible—it's the waste of intellectual resources. If you hired people so they wouldn't think, maybe it wasn't worth hiring them—maybe you should have just had machines. If you hired people for their brains, what they had between their ears, you have to use it. And if you don't use it, that's really the most serious mistake, I think, that you can make. We really need to not be alone—I tell people this—I'll only have some of the ideas, and with everyone together, we'll have other ideas, ideas I wouldn't have seen coming at all. Each person will see them from their own little perspective, but it will be interesting. And then there's another idea, I think, in Lean—it's the idea that problems are better corrected when they're addressed as close to the source as possible. And indeed, it's the people who are really in the operational side, who are the best specialists in their field, who may have proposed interesting things. So if you've completely lobotomized them by telling them 'do this, then do that, then do that,' we're not at all on the right track. So we're trying to put them back into that mindset, and in a way, that's sometimes a bit complicated. Obviously, this concerns all staff—it's not just management in companies that should bring things to the table. On that, we may not be ready yet for a company without managers—we're looking into it, but that's for later. But maybe if we've progressed enough, in 3 or 4 years, if you invite me back, I might tell you that we've crossed a threshold and that now we're ready to go further. But in any case, what I often tell them is that my dream is actually this—that they guide me, and not the other way around. They are the best experts in each of their respective fields, and if they can make good proposals for us, that will be interesting. There's another idea, the last one I'll develop here—it's the idea of an excellence pathway. There's a monstrous waste that happens in... many companies—it's that to get recognition, to get stripes, to get a better salary, people feel obliged to change roles. So you look at all the people trained in IT—many of them, after 4-5 years, are no longer in IT. They've moved on to something else—they're doing management, they're project managers, etc. And sometimes they're doing a job they don't like. There are many project managers who don't have the relational touch that's absolutely essential for that role. Some don't have what it takes to be a manager. It's a shame to lose people who are good in their field, whether in terms of business expertise or technical expertise, just because it's the only way to progress. So on that, we're also trying to innovate—we're trying to develop excellence pathways. We don't specify what type of excellence—we say it can be technical excellence or functional excellence. Someone who perfectly masters the business of one of my clients—that has a lot of value to me. And I'll try—that's what we're trying to build—I'll try to value them effectively, so they have both their knowledge and the developments, the financial compensation that goes with it, so they can actually stay in those paths. There's an important element in this—when we talk about excellence, we're not talking about experts as they're referred to today in companies. There are many experts—there are plenty of people, by the way, who are given the title of expert. It's absolutely necessary...
I think I still have 5 minutes. It's absolutely necessary that we don't devalue the term 'expert.' The person in this excellence role and recognized as such must really be almost the best specialist in the company in one of the areas in which we operate. So it won't be a product area. For example, the guy who comes to me and says 'I'm an expert in RAC,' I mean 'yeah, for me, that's not in my excellence pathway.' On the other hand, the guy who can say 'I'm an expert in data management, whether it's this or that DBMS, but I know X of them, and I can say 'this is no longer the product we used—now we should use another one,' who can say 'now, the trends in my field, in my sector, are to do this or that, and propose what comes next'—that's what I'm looking for. So I don't need expertise that's too focused on a product or something like that—it needs to be much broader. And in a way, we're in a mechanism that should work like co-optation. Eventually, you take the best—sometimes you don't always have them, and it's not something that will involve 15 people. In a given field, you'll have one, maybe two. There's a logic of tutoring, mentoring, and learning that needs to be put in place. So that's everything we're trying to build. I'm almost at the end. We talked about expectations—I need them to avoid waste with my business lines. Overproduction—I told you about potential software functions. For example, when you buy an off-the-shelf product, you have plenty of functions you don't use. And roughly speaking, when you pay for a custom-made product that does just what you need, the sky project costs you two as a requester. And of course, you pay for all the potential, even if you don't use it. So that's already overproduction. We could talk about inventory. I have a lot of people who buy me tools. That's what we do in periods when everything is going well. They buy you the best product on the market. Then you tell them, 'Wait, you bought this product and you're only using 10% of its features.' So what we're trying to do now is to say instead, 'No, wait, there's an open-source solution, or a packaged product that looks interesting,' maybe 50% of the features of the software you want to use, but when you use 80% of the features and 50% of those features, then I might think you have the maturity to buy a more expensive product that allows you to go further. But first, demonstrate the maturity. Unnecessary steps—you know about them—there are plenty of people who make local optimizations at the expense of the general interest, so that's a classic. And then regarding tests, I told you that in our industrial activity, we still need to focus heavily on what we do upstream because afterward, it's too late to correct. There you go, I'm at the very end. So, just one page. What should you take away from all this? I talked to you about liberated or open-source software, but for small expressions. I talked to you a little about the Lean approach, even though I told you that's not what we do. For us, these aren't goals—they're means. We're in a world that's moving faster and faster. That's an essential factor to take into account. When we talk about technology, for example, it evolves in an almost asymptotic way. We're at the top of the asymptote, which means people struggle to spot what's new, they struggle to study it, appropriate it, and by the time they master it, we've already moved on to something else. We're in a world of open competition, whether you like it or not—anyway, the services you provide, others can provide externally, and perhaps at a very different price level, so you have to justify these things much more. And so, the techniques we just talked about—Lean or Open Source—are quite interesting tools for companies. But there's a prerequisite—you absolutely must have agility.