Programmable companies, the next step in the CTO's evolution?

0:02 Je suis très heureuse d'accueillir Cornel Fatulescu qui est CTO de PENTALOG et qui va nous parler de scalabilité. Merci Elsa, bonjour à tous. Merci d'être là pour vous parler de Programmable Companies. Vous allez voir, ces sociétés existent parmi nous, elles seront juste de plus en plus populaires. C'est un voyage folle de nos directions de technologie. Et j'espère que la plupart d'entre vous vont se retrouver dans ce voyage. Pendant le voyage, je vais faire appel à certaines notions techniques. C'est normal, c'est une audience de CTO. Certains de ces éléments vous ont peut-être fait du mal déjà ou vous ont sauvé. Le potentiel résumé de toutes ces notions que vous ne connaissez peut-être pas.

1:06 Et pour mieux profiter de cette séance, je vous conseille fortement de regarder les titres des diapos, les bonhommes, leurs actions, pas nécessairement les textes qui sont plutôt là pour une deuxième lecture. Et ça commence. Il était une fois en situ, en situ très heureux, car il avait une opportunité de travailler avec des investisseurs sur une nouvelle plateforme de voyage, de voyage pour les personnes les plus riches. Il était surtout content, il s'appelait Bob, il était surtout content car il pouvait construire tout de zéro. Ce n'est pas nécessairement évident. On n'a pas tous la chance de faire tout de zéro. Donc, il part sur une stratégie technique lambda, assez banale pour les CTO.

2:15 Pour un site web et vendre des voyages en ligne. Il commence à travailler sur un prototype, il monte une équipe, Et avec cette équipe, il arrive à mettre en ligne, à l'échelle de cinq mois, cette nouvelle plateforme. Tout le monde est content, car c'était fait dans les règles des arts. Même les investisseurs ont été très, très impliqués dans le processus. Ils ont participé à chaque événement clé. jusqu'à l'arrivée de nouveau de la nouvelle marketing officer qui semble avoir une vision un peu différente, qui commence à leur parler de leur audience et même à reprocher entre lignes qui ne se sont pas suffisamment investis sur leur audience, qu'il fallait parler de personnes, qu'il fallait parler de touch points, qu'il fallait se concentrer sur le funnel des clients.

3:25 Et avec ce nouvel débat, il fallait intégrer de nouveaux outils. Et donc Bob se retrouve avec pas mal de nouveaux systèmes, ça c'est la plupart, et il fallait envoyer des données un peu partout. Donc, comme il avait beaucoup de systèmes, il a vu pour une première fois que son système risque d'être un peu instable, car pas toutes les données arrivaient à être... Envoyé dans le bon système à n'importe quel moment. Il s'est dit qu'il faut qu'il trouve une autre stratégie. Une stratégie qui intègre non seulement les outils marketing ou sales, mais tous les outils de son système d'information. On voit ici par exemple l'outil back-office pour la gestion du catalogue de produits. Et il a un nom pour ça. Il l'appelle DataOps. Il est très fier de cette stratégie et il commence à la mettre en place.

4:29 La bonne nouvelle, c'est que tout le monde achète. Au sens où, en fort soutien dans son entreprise, tout le monde veut faire ça. Et il arrive à bien mener le projet. Ça fait déjà 18 mois de la première jour sur le projet. Tout est en place et tout le monde est content. Il est tellement content de Bob qu'il n'arrive pas à parler. Il parle aux conférences, il parle à table. Il est juste fier. Et quand il regarde, rétroactivement, il voit qu'il a fait du chemin. Du jour zéro où il fallait mettre en place un site web, jusqu'au moment où il a mis en place DataOps, il a fait du chemin, lui, avec son équipe. Il a énormément appris. Mais dans des moments où il faut réfléchir en profondeur, il s'est dit qu'il a fait quand même tout ça juste pour avoir une clarté sur le funnel. Car c'est ça ce qu'il manquait au départ. Et il se demande s'il y a peut-être autre chose ou une autre manière à faire les choses, car 18 mois pour obtenir tout ça, c'est quand même long.

5:40 Et il s'est dit, qu'est-ce qui lui a manqué? Il lui a manqué de réfléchir en processus. En fait, quelque part, la vente en ligne est un processus, le premier processus, il fallait se concentrer sur ça. Et ce processus a des touch points. Et il y a plusieurs processus. Il y a un processus, par exemple, pour intégrer les partenaires. Et chaque processus a des paramètres, comme les touchpoints, donc les étapes par lesquelles on va passer, de cycle ou un paramètre comme le volume d'exécution. Il s'est dit qu'il doit avoir une fonction d'optimisation pour ce genre de processus. Et on peut dire que ça, c'est un peu là où il doit se concentrer dans son système. Et donc, pour remettre tout ça en ordre, il se dit, C'est dit, il sera intéressant de réfléchir tout en tant que processus. C'est un peu tard de revoir la stratégie et la vision qu'il a sur le système actuel, mais c'est quand même intéressant pour les futurs systèmes sur lesquels il va travailler.

6:42 Tout est un processus, tout est touch point. Chaque processus est tracé. Il obtient comme ça un dataset, si jamais il doit faire du machine learning, c'est naturel, et il doit juste optimiser ce processus. Mais s'il ne doit pas réviser ce qu'il fait pour ce cas-là, quand il parle de sécurité, car il a dû subir un audit de sécurité, les choses vont changer. Car il va vite apprendre qu'il a oublié des choses fondamentales à son système. Data sensitivity, qu'il fallait avoir des données qui soient gérées d'une autre manière. Et dans ce moment-là, il se dit que le refactoring est un peu trop important. Certaines données, il faut les crypter et certaines données, il faut les déplacer dans un autre endroit. Il ne sait pas comment faire pour l'instant, mais il s'est dit, futur système, car Bob, il réfléchit, il est positif. Il s'est dit, il faut d'abord partir avec Data Sensitivity in Mind, architecture des données, après comment les données coulent dans le système, sécuriser les données, comment gérer toutes ces données-là, et dans un ensemble, l'efficacité de ce

7:55 travail-là avec la bonne gouvernance. Il n'échappe pas à un refactoring, car bientôt, on lui demande d'intégrer le partenaire. Les partenaires lui disent, on ne va pas gérer de multiples identités d'utilisateurs. Et il faut surtout avoir des single sign-on et des API. Voilà, il n'est pas prêt à ça. Par contre, Bob, il essaie d'intégrer un maximum dans les principes de développement de son équipe. Il s'est dit, focus sur les API. Et c'est comme ça, les équipes vont essayer de refactoriser un peu leur système. Et s'il regarde tout en ordre, il sera intéressant que chaque opération qu'un utilisateur puisse faire dans le système soit une opération API. Il faut du API management, un brick qu'il n'avait pas, qu'il lui faut des webhooks pour des événements. Éventuellement des connecteurs pour que d'autres systèmes puissent interopérer plus vite avec eux. Il met tout ça dans un papier, il fait une nouvelle vision et il va vendre la vision, mais les autres ne soutiennent pas, car déjà il est en retard.

9:02 Il y a plein de trucs à faire pour eux, il n'a pas réussi, donc son baglog est saturé. Et donc, il a perdu un peu un support. Donc, c'est très compliqué à vendre une nouvelle vision de refactoring alors que la plupart des demandes ne sont pas adressées. Il s'est dit, mais comment intégrer tout ça? Qu'est-ce que je peux faire pour y arriver? J'ai plein de demandes à adresser, mais mon système ne tient pas. Je suis quelque part mal conçu. Il s'est dit, il faut que j'arrive. À permettre aux autres de construire ce qu'il leur faut eux-mêmes. Moi, je mets en place l'outil, l'infrastructure, et ils vont aboutir tout seuls. Donc, quelque part, il faut une politique claire, il faut une sorte de portal de self-service et les permettre à faire du self-service à eux, que ce soit du développement avec du low-code, que ce soit du data analysis pour tout ce qui est analyse de données. Et il y a d'autres outils à mettre en place, plus ou moins importants au début. mit drei important en longue durée. Il faut que tout le monde arrive à explorer les données et les applications, les découvrir facilement.

10:08 Quand il regarde derrière tout ça, il se dit« Waouh, c'est du chemin. J'ai une vision à trois ans. » Presque rien, mais j'ai une vision à trois ans. Et ça me prend un moment. Mais ce qui est important, c'est que je suis convaincu que ça va être mieux pour la société. Quelque part, Bob propose aux autres de pouvoir étendre les services de leur manière, tout en gardant le contrôle de l'IT sans exposer la société à plus grand risque. Et là, je fais une petite parenthèse. J'ai fait cette vision depuis un an et demi. Il y a déjà des résultats. J'espère que Bov arrivera bien à montrer que c'est possible dans leur société. Donc, on ne s'arrête pas là, car quelque part, cette présentation est programmable compagnie. Qu'est-ce que ça veut dire programmable company? En fait, Bob, il appelle tout ça programmable company.

11:10 Cette nouvelle vision, cette nouvelle vision qu'il a fait sur trois ans, où il s'est dit, je vais construire dans mon architecture la capacité, la possibilité que d'autres sociétés ou d'autres tiers autorisés puissent étendre le fonctionnement de mes services. Moi, je reste en contrôle. de ce qui se passe et eux peuvent étendre via des API ou la politique et tout ce que je mets en place autour de ce service. Mais pour mes équipes, il faut aussi leur donner un guide pour qu'ils puissent discriminer entre quels sont les bons choix, quels sont les mauvais choix quand ils vont décider pour incrémenter les produits. Et donc, comme principe important, on retrouve la version initiale de ce principe que vous avez eu quelques diapos avant. Mais il rajoute autre chose. Il se dit, il y a un défi quand même avec le coding.

12:15 Aujourd'hui, on pense tout avec la mentalité qu'on a, qui est du development from scratch. Il faut que les développeurs et ses équipes apprennent à utiliser d'autres outils. Comme aujourd'hui ils savent utiliser Excel, ils peuvent utiliser du low-code ou des outils de data analysis. Et tout le monde dans l'entreprise quelque part doit développer plus ou moins ce genre de compétences. Donc ça c'est une nouvelle chose car quelque part à la place de voir tout comme code, Les équipes IT doivent réfléchir automation. Et le code est juste un outil dans un boîte à outils d'automation. Et une dernière chose qui reste très très importante. Son département IT, n'arrive pas à livrer des fonctionnalités ou des produits tout seul. Il fait ça ensemble avec les autres. Donc quelque part, c'est une vision d'Haïti partagée. C'est partagé via le seul service qui a un fort impact sur la culture à longue durée.

13:17 Donc, tellement fort que Bob se demande s'il est toujours en situation. Non seulement pour ceux qui ont participé à l'autre présentation de Bob, où on parlait des CTO, on voit que ce n'est pas clair du tout qu'est-ce que c'est un CTO. Mais là, avec une vision partagée du CTO, avec quelque part un département IT où les choix se font avec les autres, où tout ce qui est livré, quelque part, ne peut être livré que si les autres lui donnent de la valeur via leurs produits qui enrichissent autour des API déjà mis en place. Donc, on est presque à la fin de cette présentation. Mais Bob, même s'il voit que c'est un défi, il est tout au début. Il a une vision sur trois ans, il a des principes dans lesquels il croit fortement. Il a l'auteur de présentation qui a d'expérience, mais qui n'a pas vu tous les fruits de cette vision implémentée.

14:32 Il est juste au milieu. Mais Bob dit, c'est un luxe aujourd'hui de penser. qu'on peut intégrer toutes les bonnes idées, toutes les bonnes fonctionnalités que les autres ont besoin. Et si les autres ont besoin, on peut leur donner les outils pour ce qui leur arrive. On peut leur donner les processus, les outils, tout ce qu'il leur faut pour que justement eux arrivent. à mettre en place ce qu'ils disent qu'ils ont besoin. Merci et je vous retrouve tout de suite pour répondre à vos questions.