Plateformes low-code : une solution à adopter ?

0:16 Bonjour à tous, je m'appelle Thomas Villaren, je suis architecte chez Payfit, que vous connaissez peut-être, qui est un leader logiciel, une solution de gestion de la paie et des ressources humaines. Et donc, chez Payfit, on utilise une plateforme low-code. Qui s'appelle le JetLang et qui nous permet d'abstraire la complexité de la paye pour pouvoir permettre aux équipes locales qui sont dans cinq pays, donc en France, au Royaume-Uni, en Allemagne, en Italie et en Espagne. Donc, ça permet à ces équipes locales de coder, de définir la logique de gestion de la paye sans vraiment coder, justement, avec une simplicité fulgurante qui nous permet de croître rapidement. Et donc d'attaquer ces différents marchés de manière très itérative. Dans le passé, j'ai également travaillé chez un éditeur logiciel de plateforme locale qui s'appelle Generative Objects, que vous connaissez peut-être. Je serai aujourd'hui l'animateur de ce meet-up, mais avant d'accueillir nos deux intervenants,

1:20 On pensait important de faire une petite mise en contexte sur le sujet du low-code et notamment des plateformes low-code, parce que le sujet est assez vaste. On a beaucoup parlé de low-code, de no-code, de plateforme no-code, d'outils no-code. Donc, on va faire peut-être une rapide mise en contexte, en particulier pour parler des plateformes low-code, puisque c'est le sujet aujourd'hui. Donc, les plateformes low-code sont des plateformes SaaS qui permettent de créer des applications métiers à usage interne ou externe, comme on le verra avec nos intervenants, sans code ou avec très peu de code. Donc, c'est vraiment le premier pendant, l'aspect SaaS qui a marqué l'émergence de ces plateformes, puisqu'en fait, pour ceux qui connaissent un peu le domaine depuis quelques années, ce type d'outils existait déjà avant, on appelait ça des Rapid Application Development Platforms, on a le concept en ingénierie logicielle de Model Driven Engineering, qui est vraiment ce concept d'abstraire, de monter en abstraction pour simplifier la manipulation du code.

2:21 Donc c'était des concepts qui étaient qui existait déjà mais qui était un peu moins accessible. C'était un peu des usines à gaz, on va dire, pour mettre en place. Mais maintenant, avec le cloud, c'est beaucoup plus simple. On a des déploiements automatisés, des accès multi-utilisateurs sécurisés, des API partout, donc on peut se connecter à plein de sources de données. Très simplement, c'est vraiment ça qui a marqué l'avènement de ce type de plateforme ces dernières années. Je le disais, ça permet de créer des applications métiers. Les plateformes low-code, c'est plutôt orienté applications d'entreprise, même si on a vu des plateformes comme Bubble qui permettent de faire des applications en public. Pour des besoins spécifiques. Donc vraiment là où les logiciels... dit sur étagère, les progiciels ne vont pas pouvoir adresser ces besoins. Et donc, il aurait fallu un développement, on va dire custom, à la main. Et la manière dont fonctionnent ces plateformes, c'est que les développeurs low-code vont configurer des composants, des blocs qui existent déjà dans la plateforme pour créer à la fois le modèle de données, les interfaces, etc.

3:24 Justement, ces blocs-là que je vous présente rapidement ici pour vous donner un peu de contexte sur comment fonctionnent ces plateformes. On va avoir généralement sur toutes ces plateformes, on va avoir ces différents blocs. La modélisation des données, c'est la définition de tous les concepts métiers manipulés. Par exemple, si vous créez une plateforme de type CRM, vous avez le concept de customer, de client, pour parler en français, le concept de contrat, peut-être le concept d'entreprise. Tous ces concepts-là que vous allez lier par des relations. C'est vraiment le data model comme on pourrait le faire quand on commence un projet classique. Vous allez avoir la définition des interfaces. Il y a généralement des outils qui vous permettent de définir quelles sont les interfaces utilisateurs, donc les formulaires, les grilles, les listes, tous les widgets que vous allez pouvoir utiliser. Et enfin, un troisième pan qui est la gestion de la logique métier. Donc vraiment en low-code, no-code. Donc on va avoir des briques, des langages, des mini-abstractions qui permettent de configurer par exemple les règles de calcul.

4:28 Ou alors de contrôler la visibilité de certains. un champ sur l'interface. Donc ça, c'est ce que j'ai appelé la logique synchrone. On va également avoir souvent des possibilités de définir des workflows de manière visuelle, par exemple, pour définir les processus métiers qui vont être... Comment dire, adressé par l'application que vous allez créer avec cette plateforme. Dernier slide, qu'est-ce qu'il y a de différence entre le low-code et le no-code? Je pense que c'est important de le rappeler aujourd'hui pour contextualiser un peu les échanges avec nos intervenants. Aujourd'hui, on va parler plutôt de plateforme low-code et potentiellement, pourquoi pas, de no-code, mais vraiment dans le giron des plateformes. C'est ce que j'expliquais, on est vraiment sur un outil centralisé qui permet de gérer un pool applicatif, qui va généralement s'inscrire dans une stratégie d'entreprise pour outiller à la fois peut-être même des utilisateurs internes ou externes. La différence entre ce qu'on appelle les plateformes no-code, comme Bubble ou Betty Blocks, par exemple, et les plateformes low-code, comme

5:31 la plupart de celles qu'on va voir sur le marché, comme Manix, Outsystem, Generative Objects, par exemple, Simplicité, qui est la plateforme utilisée par nos intervenants aujourd'hui, ou les plus classiques... De Microsoft ComboRaps. La différence, ça va être que dans les plateformes no-code, on va être vraiment restreint sur ce qu'on peut faire. On va avoir un certain nombre de blocs prédéfinis qu'on va pouvoir configurer en tant que développeur no-code, mais pour aller au-delà de ces blocs, si la logique métier est un peu plus complexe que ce que permet de faire l'outil, on va être bloqué. Il va falloir souvent utiliser peut-être du function as a service pour faire du vrai code derrière une API et ensuite le lier à la plateforme pour pouvoir adresser ça. S'il faut créer des widgets un peu plus... Customiser c'est peut-être un peu plus compliqué, alors que la plateforme Le Code va intégrer en natif l'extension de code, que ce soit pour la logique métier, pour les modèles de données éventuellement, pour les widgets, les interfaces graphiques également. Donc rapidement sur les outils no-code, Un sujet dont on ne parlera pas aujourd'hui.

6:32 Les outils no-code, on en parle de plus en plus ces temps-ci. Donc, c'est des outils qui vont être plutôt là pour augmenter la productivité. Généralement, un outil va adresser un besoin particulier. Donc typiquement, sur les différents piliers que je vous ai présentés, on va avoir des outils comme Integromat, Zapier, YPTT, qui permettent de faire des workflows, mais vraiment se focaliser sur l'aspect workflow. Puis on va avoir des outils comme Webflow, qui vont permettre de faire plutôt des interfaces. Donc c'est vraiment des outils très spécialisés, donc il faut les combiner si on veut vraiment créer des applications. Et qui dit combinaison de plusieurs outils comme ça sur l'étagère, dit potentiellement des limites en termes de fonctionnalités, et puis derrière de scalabilité. Donc, juste pour terminer, j'avais une dernière slide bonus. Je dis que c'était la dernière slide, mais ce n'était pas la dernière slide. Donc, un petit aperçu, alors vraiment pas exhaustif du tout, mais de quelques plateformes qui existent.

7:33 Donc, les plateformes en haut à gauche, c'est un petit clin d'œil, c'est Simplicité qui est la plateforme utilisée par nos intervenants aujourd'hui et Generative Objects qui est mon ancien employeur. Il y a en haut à gauche Mendix Outsystem, Pega, ce sont les plateformes. Qui sont identifiés comme des pure players, vraiment des plateformes low-code, identifiées comme des pure players par Gartner. Betty Blocks et Bubble, c'est dans le même groupe, mais plutôt des plateformes qu'on va appeler no-code. Et puis, bien sûr, il y a Salesforce, Amazon. Microsoft qui ont leur propre plateforme, et puis je vous ai mis quelques autres acteurs assez connus dans le monde du low-code, mais il y en a de plus en plus, certains se créent rapidement et puis disparaissent aussi rapidement, malheureusement pour eux. Mais c'est vraiment un marché, un écosystème en pleine évolution. Aujourd'hui, je vous propose d'accueillir deux intervenants, Alexandra Hallard et Nicolas Delemer. Ces deux intervenants utilisent tous les deux une plateforme low-code, ont mis en place une stratégie low-code au sein de leur entreprise, de leur structure. Et directeur adjoint de l'ANSM, l'Agence Nationale de Sécurité du Médicament, et donc au sein de son entreprise, Alexandra est directrice développement commercial du groupe BPCE.

8:44 Donc Alexandra et Nicolas, je vous propose de monter sur scène avec moi pour... Pour échanger avec nous. Alors, je vois Nicolas arriver. Je vais arrêter mon partage d'écran. Bonjour à toutes et tous. Bonjour. Bonjour. Merci Thomas. Avant de commencer et de poser une première question pour lancer les débats, je vous rappelle à tous le chat et notamment l'onglet Q&A pour poser vos questions. Vous pouvez aussi lever la main pour monter sur scène et poser la question directement ou la poser sur le chat et puis je vous proposerai de monter sur scène si vous avez envie. Mais ce n'est pas une obligation, bien sûr. Alexandra, Nicolas, je vous propose peut-être de vous... et de présenter vos contextes respectifs. Je ne sais pas qui veut commencer. Je sais pas, je vais démarrer. Alors moi, Alexandra Allaire-Busteau, en fait, je suis directrice du développement commercial au sein du groupe BPCE.

9:45 Donc le groupe, je pense que tout le monde le connaît, donc il y a sur eux. Moi, je suis issue d'une formation supérieure en finance et j'ai un parcours plutôt bancaire. Je suis banquière à la base et puis après, je suis... J'ai travaillé dans l'informatique bancaire. Donc, chez moi, en fait, au sein de la direction, on gère la gestion de l'offre et de la demande de services pour les clients. On est sur une relation client B2B, mais issue, driveée par le B2C. On gère toute la relation client, en support à la relation client, et puis aussi l'intégration de la connaissance de nos produits. Merci, je vais prendre la suite. Nicolas Delemer, je suis le DSI adjoint de l'ANSM. J'ai une formation plutôt technique. J'ai eu un master en intelligence artificielle il y a pas mal de temps déjà maintenant. Je travaille pour l'ANSM depuis 7-8 ans. J'ai eu un parcours classique de chef de projet, de chef de pôle, et plus récemment, depuis deux ans et demi maintenant, de DSI adjoint.

10:58 Une de nos préoccupations, c'est effectivement de rationaliser un peu le SI et de travailler sur tout ce qui est efficience. On en parlera après. La NSM, en quelques mots, pour ceux qui connaissent et qui suivent l'actualité tout simplement en ce moment, c'est l'Agence Nationale de Sécurité du Médicament. On la connaît plus sous le nom d'Agence du Médicament, puisque c'est une agence qui a changé plusieurs fois de nom, Agence du Médicament, AFSABS et maintenant ANSM. Actuel de l'agence, notamment sur ce qui concerne les problèmes de... sanitaire actuelle, c'est en l'occurrence de valider les demandes d'AMM, donc les autorisations de mise sur le marché des médicaments, et aussi de surveiller et de contrôler le marché. Donc actuellement, on a une grosse activité sur les vaccins, sur leur autorisation avec l'EMA. Il y a une décision d'ailleurs qui est attendue cet après-midi de l'EMA. Mais aussi sur toute la surveillance du marché, sur les signalements qui nous sont remontés, notamment quand on vaccine la population actuellement. Merci à tous les deux.

12:01 Pour lancer les débats, je vois qu'il y a déjà quelques questions. On va peut-être déjà remettre en contexte vos usages du low-code pour comprendre un peu chacun comment vous utilisez la plateforme low-code. Comme je l'ai dit, vous utilisez Simplicity Software, qui est un logiciel français qui propose une plateforme low-code. Je ne sais pas. Je vois la première question sur les plateformes qui ont le vent en poupe. Alors, Alexandra, peut-être une réponse différente de la mienne. On n'a pas fait une étude de marché récente sur les plateformes low-code. On a choisi notre plateforme low-code maintenant, il y a quelques années. Et on a fait ce choix finalement plus sur le côté rendu de service et orientation de la plateforme. Est-ce qu'on est sur une plateforme qui s'oriente modèle métier, sur la partie workflow, sur la génération ou l'interprétation de code? On sait qu'il y a un risque.

13:02 Certaines des plateformes sont des plateformes qui sont récentes. Maintenant, ce risque est maîtrisé, c'est-à-dire qu'on va essayer de ne pas mettre tous nos oeufs dans le même panier. On va essayer de sécuriser les partenariats qu'on a avec nos prestataires, et en l'occurrence avec Simplicité pour ce qui nous concerne. Donc voilà, moi je n'aurais pas de… Je vais peut-être frustrer la personne qui a posé la question, je ne sais pas quelles sont les plateformes low-code qui ont le vent en poupe, mais en tout cas, de ce qu'on voit avec Simplicité, c'est qu'on a de plus en plus de partenaires qui travaillent sur cette technologie-là. Et aussi, j'entends partenaire, c'est tant intégrateur qu'établissement public qui travaille avec simplicité. Ce qui nous rassure de notre côté. Alexandra, je ne sais pas si toi tu as... Alors moi, je n'ai pas vu la question, mais... Tu peux te l'écrire. Tu as en haut à droite. Ah, d'accord. Voilà. En fait, moi, je m'intéresse au low-code depuis une dizaine d'années.

14:03 Donc, j'ai fait beaucoup d'intégrations, en fait, de progiciels de finance, SAP, PeopleSoft. Pour moi, en fait, je n'ai pas de visibilité par rapport aux autres plateformes, puisqu'étant donné que nous, on a fait un dossier de choix en standard d'outils pour nous équiper, pour supporter notamment la gestion de la relation client. Et au final, on avait étudié différentes solutions. et est apparue aussi dans le panorama la plateforme Le Code Simplicité. Donc, en fait, on a plutôt comparé l'intégration de Progiciel Éditeur avec une plateforme low-code. C'est plutôt ça qui a en fait drivé notre choix. Et quand on a fait l'étude de choix en amont du projet, on a rapidement orienté la décision sur le low code. Pourquoi? Parce qu'en fait, on a toujours un métier. qui a 50 000 besoins différents, on a du mal à le faire converger. Et en fait, toutes les plateformes de la place qu'on a étudiées dans le dossier de choix, elles répondaient à 30 à 40% du besoin des métiers.

15:11 Donc, Je t'en prie, Alexandre, continue. Et donc, en fait, on s'est dit, étant donné qu'on est déjà, nous, dans une organisation agile à l'échelle, on a déjà des méthodes de gestion de projet agile, on s'est dit, si on veut être hyper agile, on peut aussi s'orienter vers une plateforme agile. Étant donné que les besoins étaient aussi en effervescence au niveau du métier, on était en train de repenser la stratégie de la relation client. Et donc, on a pris l'option de prendre simplicité. Bien sûr, pour d'autres, je l'évoquerai peut-être après, mais aussi d'autres critères. Donc moi, à l'heure actuelle, je n'ai pas étudié d'autres solutions de code. Alors, je complète juste. Du coup, ça m'a fait penser à quelque chose. Effectivement, dans votre choix de plateforme, il y a une chose aussi qui est importante, c'est penser, quoi qu'il arrive, à la réversibilité. C'est-à-dire que quoi qu'il se passe, quelle que soit la plateforme, même si elle est pérenne, le modèle économique peut lui être différent dans quelques années.

16:12 Je pense notamment à Microsoft, quand vous partez avec eux. On sait que la plateforme va être pérenne globalement, mais rien ne dit que le modèle économique dans 4 ou 5 ans vous conviendra toujours. Donc, il faut avoir en tête une réversibilité sur d'autres outils. Et la seule chose qui est un invariant, c'est la donnée, en fait. Donc, Quand on a fait notre choix de plateforme, notamment Simplicité, on s'est posé la question d'est-ce qu'il était facile de récupérer les données en travaillant sur le modèle de données de Simplicité, et la réponse était oui. C'est-à-dire que sur la technologie Simplicité en tout cas, qui est sûrement vrai sur d'autres plateformes locales, mais pas sur toutes en tout cas, on travaille d'abord sur le modèle de données et ensuite il est interprété pour générer les écrans. Et ça, c'est quelque chose qui nous a beaucoup plu puisqu'on préfère maîtriser les données. Et avoir des écrans qui sont à 80% ce qu'on veut, plutôt qu'avoir des écrans parfaits, mais qui génèrent un modèle de données qui sont parfois incompréhensibles, et donc du coup, en cas de réversibilité, très compliqué à aller récupérer.

17:13 Donc, c'était pour une petite info sur le choix de... Peut-être sur ce sujet, justement, je vais rebondir. Il y a une question qui parle des plateformes plutôt d'outils comme Zapier, Integromat, qui sont des outils peut-être plutôt de workflow, mais on peut généraliser un peu cette question. C'est, n'y a-t-il pas un risque accru au niveau sécurité d'exposer des flots problématiques légals, RGPD, les législations américaines, etc.? Est-ce que ça, ça a été un critère pour vous du choix de la plateforme, notamment, je parlais de données, Nicolas, le stockage de la donnée, notamment par rapport à votre stratégie, ça, sans le prémice, je ne me souviens plus exactement quel type de cloud vous utilisez, il me semble que c'est sur des clouds privés, c'est bien ça? Nous, c'est du cloud privé, mais en tout cas, Simplicité permet de faire aussi du on-premise. Je crois que... Thomas Ripolt, qui est un des fondateurs de Simplicité, l'avait précisé dans le chat. Initialement, on était, et d'ailleurs, on a des applications qui sont on-premise, qui ne sont pas dans le cloud, pour les applications sensibles notamment. Et on s'est quand même doté d'un marché.

18:13 Je rappelle qu'on est un établissement public, donc on est soumis à beaucoup de contraintes. Établissement public de santé, soumis à beaucoup de contraintes de sécurité. Et donc, effectivement, on s'est doté d'un marché d'hébergement avec un hébergeur de données de santé. Donc, la question, elle est pertinente, mais je pense qu'elle n'est pas que liée à du low-code. C'est les mêmes questions qu'on se posait déjà avant avec du développement spécifique. Après, c'est vrai que c'est plus facile. Alexandra le disait tout à l'heure, on va générer plus d'applications, ça va être plus facile. Une stratégie peut être de mettre ce type d'application low-code dans les mains des utilisateurs et c'est là qu'il y a de nouveaux risques qui apparaissent. Nous, on a fait le choix de garder cette plateforme au sein de la DSI pour pouvoir être garant de la sécurité des données et de sécuriser tout simplement les différents flux qui sont liés à ces applications. Je ne sais pas si Alexandra, tu as des choses à rajouter là-dessus. Non, non, je n'ai pas du tout un profil technique.

19:16 C'est vrai. Nicolas, c'est pas du tout mon expertise, mais nous, on a bien sûr fait appel à la contribution des équipes de la DSCI du groupe et de la conformité afin de nous assurer de la réponse aux exigences. Réglementaire et la plateforme répond complètement après nous on a plutôt centralisé alors pas la dsi pas comme nicolas on a centralisé en fait au sein de mes équipes l'administration en fait de la plateforme métier pour les utilisateurs mais c'est aussi un métier voilà donc en fait on est quand même un petit peu gardien du temple en laissant de la souplesse l'avantage de simplicité, c'est vrai et c'est aussi un risque, c'est que dans une intégration de projet CIEL, on a à peu près, on va dire, un ratio de 80% de développement, 20% de paramétrage. Et là, dans une plateforme low-code, on a le ratio inverse. Et en plus, dans le paramétrage, dans les 80% de paramétrage, on a quand même une large...

20:21 Possibilité de paramétrage à la main du métier. Donc, c'est vrai que ça peut être un risque aussi vis-à-vis des exigences réglementaires. Mais donc, nous, cette administration métier, on l'a internalisée. Donc, on s'assure, bien sûr, de s'affranchir des risques potentiels. Je vois qu'il y a... Je suis désolé Antoine, mais je vois la question d'Olivier Drouard qui était ma première question et je pense que c'est vrai que c'est important parce qu'on manque peut-être un peu de contexte pour certaines personnes. On n'a pas expliqué exactement à quel besoin vous répondiez au sein de vos structures respectives. Avec la plateforme Locode. Je ne sais pas justement, Alexandra, si tu veux continuer de nous expliquer un peu ce que vous devez rester comme besoin chez BPCE. En fait, nous, la plateforme, elle supporte la gestion de la relation client. Donc, on a à peu près 45 000 points de contact dans l'application. Et donc, on gère au quotidien la relation, elle est remontée, la gestion également de l'offre, de l'offre de services, des produits bancaires et de la demande.

21:29 On est... Chez nous, je l'ai dit tout à l'heure, en organisation agile à l'échelle. Donc, on a des produits qui sont organisés avec un product owner, une équipe de développement, des scrum masters. Donc, ça, c'est pour gérer les produits bancaires. Et puis, il y a en fait des équipes qui sont auto-organisées. Alors, grâce à la plateforme, on adresse des workflows un petit peu dans tous les produits. Donc, ça, c'est le côté pratique. Et donc, on assure le cycle retour, la boucle retour, en fait, de la gestion de demande. Donc ça, déjà, on supporte de bout en bout la gestion de la relation client. Ça nous permet de partager également la connaissance. Dedans, on a toute la connaissance client sur la plateforme. Donc, ça permet aussi de la diffuser, de la maintenir à jour. Et on gère aussi tout le catalogue des services, une fonction de gestion de l'offre, de tous les services qu'on peut offrir au sein du groupe. Et puis, on gère également ce qu'on parle entre guillemets, la smart data, c'est-à-dire toute la connaissance du système d'information bancaire, dans l'utilisation qui est faite par les utilisateurs.

22:41 Donc, quand je parle d'utilisateur, c'est le conseiller agence. Voilà, donc on a ces quatre bruits qui sont couverts dans la solution. Donc, on voit bien aussi qu'on était arrivé aux limites des produits intégrateurs, éditeurs sur la place, parce qu'on a aussi, et puis chaque organisation, On est une organisation assez atypique, qui est historique. Et donc, on voyait bien que notre fonctionnement était atypique par rapport à des produits qui étaient déjà très structurés. Voilà. Et donc, en fait, on gère de bout en bout. Mais alors, on est en évolution. On fait des évolutions en ce moment tous les mois. Alors, c'est des petites évolutions parce qu'effectivement, la plateforme Locode nécessite peu de développement. Donc, on fait des petites évolutions, mais c'est des grands pas pour nous. Voilà. Ça aussi, c'est un vrai plus. Voilà. Donc, en fait, moi, dans l'application Simplicité, qui est notre application chez nous, on gère tout de bout en bout le 360, en fait, du client.

23:46 Et donc, au niveau du... Vous étiez le conseiller, en fait, en agence, c'est ça? Non, en fait, on est en relation B2B. Alors, on est une organisation qui est décentralisée en région, au sein du groupe. Et donc, on gère la relation avec la plateforme en B2B, mais qui est driveée par le B2C. En fait, ça concentre, ça massifie. C'est pour ça qu'on n'a que 45 000 points de contact. Ok. Et côté ANSM, il me semble que le pool applicatif est assez divers. Oui, on a pas mal d'applications, un peu moins d'une dizaine actuellement. C'est des applications de gestion notamment. Je peux vous prendre deux cas très rapides. Un premier cas interne, c'est une application de suivi transverse de dossiers. C'est une des premières applications, c'est la deuxième qu'on a fait avec simplicité. C'est une application qui permet à nos agents internes, à nos évaluateurs, qui sont des pharmaciens, des médecins, de suivre le traitement des dossiers qu'on confie à l'ANSM. Je parlais tout à l'heure des demandes d'autorisation de mise sur le marché des médicaments, des variations.

24:49 Quand il y a une notice, par exemple, d'un médicament qui n'est pas conforme ou qu'on doit modifier l'analyse d'un dossier de publicité, ce genre de choses, ce sont des dossiers qui ont des temps réglementaires de réponse. Et donc, on a développé une application Simplicité qui nous permet de suivre un calendrier réglementaire et d'affecter des tâches à des agents, avec des pilotes qui sont à la manœuvre sur ces dossiers. Donc ici, on va avoir quelques centaines d'utilisateurs à l'agence. Je rappelle que l'agence, c'est à peu près 930 personnes, 930 agents, et on va taper sur quelques centaines de personnes. Je n'ai plus le chiffre en tête, mais on doit être autour de 150-200 utilisateurs internes à l'agence. Ça, c'est la première utilisation. Donc, c'est du classique application de gestion. Ensuite, on va utiliser cette application beaucoup pour développer des portails télédéclaratifs. Donc là, pareil, dans une optique de s'ouvrir vers l'extérieur et de dématérialiser un certain nombre de procédures à l'agence, qui étaient initialement des PDF envoyés par mail, on va utiliser Simplicité pour développer rapidement des petits portails.

25:55 Le dernier en date et qui sera mis en œuvre, on croise les doigts, semaine prochaine avec M. Olivier Véran, c'est la mise en place d'un registre de suivi du cannabis médical. Donc ici, on est sur une application de suivi entre le patient, les professionnels de santé, que sont les médecins et les pharmaciens, pour suivre finalement cette expérimentation qui va s'étaler sur un peu plus d'un an et demi de mémoire. Donc là, on va avoir beaucoup d'utilisateurs. Plusieurs milliers d'utilisateurs. Alors, pas un instant T, on en parlait tout à l'heure en off, c'est plutôt des besoins ponctuels, ça va être l'inclusion du patient initial et après son suivi au cours de l'expérimentation. Mais ça répond aux besoins. On est rarement limité par la plateforme. Là, je cherche à quel moment on pourrait être limité par la plateforme. Mais en dehors de progiciels qui font déjà tout tout seul, j'entends là des progiciels de gestion de paye, RH, etc., où on ne va pas redévelopper ça avec simplicité, aujourd'hui, tous nos besoins sont quasi couverts par la plateforme low-code.

27:14 Merci pour vos réponses. Il y a une question d'Antoine, au Rilambal. Je ne sais pas si Antoine, tu veux monter sur scène. Dans ce cas-là, je t'invite à lever la main pour la poser. Je ne pense pas que nos intervenants pourront répondre à la question précisément sur... Sur quelles sont exactement les plateformes qui ont un outil et une équipe de dev confirmée, puisque je pense que vous avez l'expérience d'une seule plateforme. Par contre, il y a une question sous la sente qui est assez intéressante, qui est sur les profils. Bonjour, je vais couper la caméra, excusez-moi, parce que ça clignote un petit peu. La question qu'il y avait derrière, c'est qu'on avait un équipe de développement qui ferait sinon des développements en développement custom, et on se pose la question, quel outil permettrait avec toute la flexibilité et du long terme en tête, d'être mis dans les mains des développeurs et donc de remplacer les développements custom par des développements sur cette plateforme low-code.

28:21 Là où, quand on parle de no-code, c'est souvent pour mettre dans les mains de no-codeurs, donc des gens qui ne sont pas forcément des développeurs de métier. Et c'est deux use-cases assez différents. Celui de no-codeur est très souvent couvert sur Android ou dans les différents use-cases, quand on parle de no-code en ce moment, mais celui de mettre dans les mains des développeurs, beaucoup moins. J'ai entendu simplicité qui du coup a l'air d'être... Un bon candidat, mais qu'est-ce qu'on trouve pour aller vraiment augmenter la productivité des développeurs ? C'est un peu la question derrière. Sur la partie productivité, sur ce dernier mot-clé, clairement, elle augmente. C'est pour ça qu'on a choisi cette plateforme low-code. Aujourd'hui, quand on fait un petit retour d'expérience entre un développement spécifique et low-code, et notamment STD, puisque l'appli dont je vous parlais tout à l'heure était initialement développée en spécifique PHP, et elle a été redéveloppée en low-code, le gain de temps en termes de développement est de 2 à 3. C'est-à-dire que sur un développement d'une centaine de jours spécifique, on peut estimer qu'en une trentaine de jours, on a l'équivalent en low-code.

29:23 Donc, le gain est énorme. Après, si vous voulez, je détaillerai un petit peu plus parce que ce chiffre peut être mal interprété. C'est-à-dire que le temps de dev est effectivement vraiment réduit. Les délais, parfois, sont... Moins réduit. J'entends par là que nous, nos contraintes CNIL, RGPD, etc. Sont toujours présentes, low code ou pas, et ça ne change finalement pas grand-chose. Et donc, on arrive finalement avec des délais de projet qui sont réduits, mais cette fois-ci, pas d'un facteur 2 ou 3, plutôt d'un facteur 1,5, voire 2, en raison de ces délais incompressibles qu'on va avoir à côté. Donc oui, c'est vraiment plus efficace. Après, il faut, je pense, en discuter aussi avec les développeurs, que nous, on en a discuté avec des développeurs internes. Ce n'est quand même pas la même philosophie, c'est-à-dire qu'à voir quelle est leur vision du développement, c'est beaucoup moins technique finalement, c'est ce qu'on attend de cette plateforme Le Code, c'est le but. On est plutôt orienté métier dès le démarrage du projet, on va tout de suite discuter avec nos interlocuteurs MOA et métier.

30:25 On va travailler sur de la modélisation plus que sur de la technologie, quel framework on va utiliser, comment je l'implémente, etc. Donc, c'est un peu un changement de métier aussi. Ça plaît ou pas. Certains développeurs un peu roots ne seraient peut-être pas pour. Mais voilà, en tout cas, ça fonctionne comme ça. Chez nous et on voit un vrai gain finalement sur ces plateformes-là. Je ne sais pas si ça répond en fait à votre question. Non, Antoine, je ne sais pas si Antoine est sur le scène. Nous, on avait fait un test en interne avec des développeurs. Je pense qu'il faut voir ce que c'est. Il faut tester une table de code pour... Pour pouvoir se rendre compte de ce que ça change en termes de métier pour un développeur qui avant ne faisait pas de low code, voire de no code.

31:29 Super, merci. Effectivement, j'avais perdu le bouton de micro pour répondre, mais oui, merci pour la réponse. Je comprends ce qu'elle peut apporter en productivité. Après, je me posais la question de quels outils on trouve sur le marché, mais il y a eu des éléments de réponse dans le chat, donc c'est parfait. Je pense qu'on a les réponses à toute la question initiale. Merci à vous. Merci. Parfait, merci Antoine. On a beaucoup de questions techniques. Elles ne sont pas pour moi. Non, pas du tout. Passionnant. Dès que je parle de la partie... On va... Oui, voilà, je ne sais pas si Peter veut monter sur scène pour préciser sa question, sinon je vais déjà la lire. C'est, faut-il une architecture orientée API mature pour mettre en œuvre le local efficacement? Ou plus généralement, y a-t-il une barrière à l'entrée pour le low-code? Je pense qu'il y a effectivement une question technique derrière, qui est, quelles sont vos sources de données, notamment? Et c'est peut-être qu'Alexandra pourra en parler également après.

32:33 Et plus généralement, sur la barrière à l'entrée, on y reviendra après. Alexandra, je te laisse préparer. Je vais vous donner mon avis, je n'ai pas la science infuse non plus, il y a sûrement des débats là-dessus, mais mon avis est que non, très clairement, je pense que ce n'est pas un prérequis. Je dis ça parce qu'on avait un SI à la NSM qui était très vertical, très peu apaisé finalement et avec peu de transversalité. Donc voilà, un SI qui a été développé il y a 25 ans. Et on a fait le choix dans notre stratégie finalement de se doter de quatre outils qui devraient permettre de répondre à la majorité de nos besoins. Et dans ces outils, il y a un ETL qui est en l'occurrence Talent. On a fait le choix de Talent. qui travaille de concert avec Simplicity. Pour vous parler des deux autres outils, il y a Talent, il y a Simplicity pour la partie développement applicatif, il y a la partie ClickView pour la partie BI, et il y a la partie GED avec C6 et NI.

33:35 Avec ces quatre outils-là, on est capable de répondre à un grand nombre de besoins à l'agence et ils travaillent de concert, c'est-à-dire qu'on peut effectivement brancher Talent sur Simplicité, sur la plateforme low-code, sans aucun problème. Mais ce n'est pas un prérequis. On a des applications aujourd'hui qui sont plutôt autonomes, qui sont dans leur coin. Parce qu'il n'y a pas de besoin particulier d'aller se pluguer à des référentiels à droite à gauche, et d'autres applications, comme notamment l'application STD, qui est liée à une autre application qui gère les entrants sortants, qui est liée à notre référentiel de médicaments. Et le côté API dans Simplicité et connexion via des web services est natif, en fait. La plateforme ne pose aucun problème là-dessus. Donc, j'ai envie de dire plutôt au contraire, elle va, cette plateforme, vous aider peut-être à transformer un système qui est peu appaisé, qui est peu communiquant, en un système à terme communiquant. Mais pour moi, ce n'est pas un prérequis. Et si vous l'avez déjà, c'est tant mieux, il s'insérera très bien, je pense, dans votre récit.

34:45 Merci Nicolas. Alexandra, je généralise un peu la question, parce qu'il y avait une deuxième partie qui était sur, y a-t-il une barrière à l'entrée pour le low-code? On a parlé de la potentielle barrière à l'entrée. C'est vrai que c'est disruptif en interne, La phase, je dirais, avant-vente, pour être commerciale, en interne, elle est un petit peu compliquée. C'est pas… Bon, en plus, moi, je suis dans un groupe où… Ben voilà, la plateforme du SI Banker, c'est un développement interne. Il y avait cette volonté d'externaliser tout ce qui était support au Corbusier, je l'ai dit tout à l'heure. Mais pour autant, cette nouvelle technologie, parce que bien sûr, en termes de support à la gestion de la relation client, il y a des plateformes, il y a des gros éditeurs qui sont sur la place. Donc, il faut vraiment défendre ses choix. Et ça, c'est vrai qu'en interne, c'était un petit peu long pour convaincre. Je pense qu'il faut, enfin moi je l'ai, il faut la fibre intrapreneur. Voilà. Moi, on dit de moi que je suis intrapreneuse, mais c'est vrai qu'il faut faire beaucoup de sensibilisation et de démonstration en interne.

35:56 Moi, j'ai eu beaucoup de difficultés à la vendre pour l'installer. On a fait un proof of concept déjà pendant six mois pour démontrer, en fait, pour concrétiser des premiers résultats. Et c'est à l'issue de ce FOC. qu'on a pu vendre la plateforme et la déployer. Merci. La question suivante qui est la plus votée, c'est la question de François Zaninotto. Est-ce que François veut monter sur scène? Je pense que ça va faire un peu écho à la question d'Antoine précédemment. Peut-être qu'on peut y répondre. Tiens, voilà, je vois que François arrive. Татья. Oui, peut-être pas. Bonjour, merci de prendre ma question. C'est une question management quelque part. Est-ce que les gens qui les utilisent chez vous, ce sont des gens qui d'habitude font du code ou des gens qui ne sont pas du tout des développeurs?

37:05 Ce qu'il y a derrière, c'est que... Si vous utilisez des développeurs pour fabriquer des applications de code, est-ce que quelque part ils ont une efficacité supérieure avec une souris qu'avec un clavier? Ce qui est souvent une question pour les développeurs. Et aussi, est-ce que quelque part, ça n'a pas un énorme intérêt d'utiliser une plateforme low-code par rapport à un framework? Alors, j'utilise un gros mot, mais derrière les deux, à peu près la même, c'est d'utiliser des briques. Pré-fabriqué pour accélérer le développement d'applications. Un framework, ça s'utilise avec du code. Une plateforme de code, ça s'utilise avec une interface graphique. Mais en définitive, si c'est les développeurs qui font l'application, pour eux, il n'y a pas de grande différence. Voilà, c'était le sens de ma question. Tu veux répondre, Alexandra, ou je réponds? Non, je t'en prie, je compléterai après avec une vision métier.

38:07 D'accord, alors je vais apporter la vision technique. Donc non, il y a quand même une grosse différence entre les deux. Pour avoir moi-même fait du développement Java à une époque, reculer de struts pour ceux qui se souviennent, même si les frameworks ont quand même fait beaucoup de progrès, On est dans la simplicité. Alors, le nom de la technologie, la simplicité, vient peut-être aussi de là, mais on a vraiment des gains de temps. Il faudrait presque, alors c'est très réducteur, mais le comparer à ce qu'on pouvait faire avec un utilisateur avec du Microsoft Access à l'époque, où on dessinait un écran et puis... Moi, très concrètement, ce que je vois, c'est que dans mon ancienne entreprise, on avait des kits de développement. Donc, on nous fournissait les kits où on avait déjà les frameworks packagés. Il y avait vraiment la base de travail était présente. Mais pour avoir les premiers écrans et pour avoir les premières logiques métiers, il fallait quand même quelques jours, voire quelques semaines. Ici, avec la techno low code, on décrit finalement, déjà quand on fait un cahier des charges, notre prestataire est quasiment capable de monter quelque chose au bout de 5-6 jours en disant, voilà, grosso modo, ce que j'ai compris de votre cahier des charges et voilà ce que ça génère en termes d'écran derrière.

39:17 C'est un gain de temps énorme. Il y a une vraie différence. Et pour répondre à la question des profils, chez nous, on a fait le choix de garder des profils de développeurs, même si c'est un prestataire essentiellement qui travaille pour nous. Ça reste des profils de développeurs et aussi, dans notre méthodologie de projet, on fait appel à des architectes et notamment un architecte de données. Plutôt un architecte technique, puisque je pense que pour un développement spécifique, on va faire appel clairement à un architecte technique qui va travailler. sur le projet. Ici, le gros du sujet reste le modèle de données. Donc nous, on a un architecte, une d'ailleurs, architecte de données, qui va modéliser finalement avec les bonnes pratiques nos objets métiers qui vont mettre en musique finalement, la plateforme et nous générer notre application ou interpréter plutôt ce qui était paramétré pour en faire une application. Donc, c'est un choix qu'on a fait. Après, je sais que d'autres clients ont fait le choix de mettre dans les mains de MOA avancé. Je précise avancé. C'est ce type d'application, enfin de technologie low-code.

40:22 Mais il y a quand même une sensibilité technique à avoir. Il y a des choses, on peut faire des bêtises quand même. Ça reste du low-code, ce n'est pas du no-code pur. Et puis, dans un monde où la sécurité joue un vrai rôle, prend de plus en plus de place, on le voit dans le domaine de la santé, il y a des attaques sur les systèmes d'information des hôpitaux régulièrement, quasiment toutes les semaines. On ne peut pas se permettre, en tout cas chez nous, de ne pas avoir la main sur l'application qui est mise en production. C'est des profils développeurs, mais pas aussi experts qu'avant, qui ont plutôt une appétence MOA à communiquer. Vous pourriez presque vous passer d'une MOA, c'est-à-dire qu'une petite équipe de devs bien câblée pourrait directement discuter avec le métier et faire l'application. Nous, on a encore une MOA, une MOE pour faire ça. Mais ce n'est pas exactement les mêmes profils que quand on développe sur du pur spécifique, je trouve. On n'a pas du tout la même organisation dans la relation éditeur, parce qu'on fait appel à un intégrateur éditeur.

41:27 C'est un choix de ne pas internaliser les compétences sur simplicité chez nous. Pour autant, mes équipes gèrent l'administration de l'application, l'administration métier en fait. L'application, ils font du paramétrage, ils sont assez autonomes. Donc, on n'a pas du tout, comme Nicolas, fait le choix de faire développer en interne. On s'appuie. Pardon, excuse-moi, Alexandra. J'ai dû pas être clair. Le seul profil qu'on a en interne, c'est notre architecte de données. Mais c'est une prestataire, en l'occurrence, qui est en ce moment, qui travaille pour nous. Voilà, et donc, en fait, on gère l'administration au sein de mes équipes. Et donc, moi, je pense que de ce que j'en ai vu, en fait, avec l'intégrateur, l'avantage, c'est qu'on est sur des cycles courts. On répond à des gros besoins métiers qui nous auraient pris énormément de temps. Et finalement, avec une administration en interne de l'application et puis les partenaires éditeurs et intégrateurs, en fait, ça répond vraiment à notre besoin et on s'affranchit d'avoir à internaliser la compétence.

42:34 Mais après, c'est une stratégie applicative interne au groupe. Mais bon. Merci à tous les deux. Merci François pour ta question. Et au revoir. Il y a deux questions au coude à coude. Il y a une question de Mohamed sur les mises à jour. Je ne sais pas si Mohamed, tu veux venir poser ta question sur scène, sinon je peux la poser. On ne voit pas de notification. Avez-vous fait des upgrades de version de la plateforme? Oui, on en fait. Alors, pas aussi régulièrement qu'on devrait. Je pense qu'on a encore à s'améliorer, nous, à l'ADS et l'ANSM là-dessus. Il y a des mises à jour régulières de la plateforme. On en fait. Franchement, on n'a pas de problème particulier. Au contraire, c'est simple. C'est-à-dire que si je reprends un petit peu la discussion précédente, beaucoup de nos applications avant étaient dans des technologies PHP 4 ou PHP 5.

43:36 Le passage au PHP 7 a été parfois douloureux. C'est aussi une des raisons qui fait qu'on part sur du low-code, puisque là, on est soit sur du code interprété ou généré, mais dans tous les cas, on change, j'ai envie de dire, si je prends une image, on change le moteur et l'upgrade se fait via ce moteur qui est mis à jour et qui est, en tout cas, avec simplicité, de la responsabilité de l'éditeur. Donc, je n'ai pas grand-chose d'autre à dire que ça se passe bien. Ok, merci. Alexandra, peut-être la question suivante, la question de Guillaume. C'est sur l'obsolescence technologique des plateformes low-code? Sur la pérennité de ces plateformes. Oui, c'est ça. C'est ton Nicolas. Oui, je regardais le chat en même temps. Non, mais je peux aussi en parler.

44:37 Après, encore une fois, ça reste de la stratégie. C'est-à-dire que c'est la question qu'on se pose, quelle que soit l'application, un progiciel, du spécifique ou autre. Donc, la pérennité, oui, dans l'idéal. Je pense que si on avait été une plus grosse DSI et si on avait eu des moyens peut-être différents, on aurait peut-être choisi deux plateformes locales pour ne serait-ce que les mettre en concurrence. pouvoir les comparer, etc. Mais honnêtement, pour faire écho à ce que je disais en introduction, à partir du moment où on anticipe finalement le pire, c'est-à-dire l'arrêt de la plateforme, Il y a un risque, bien sûr, mais on est serein sur ce qu'on pourra faire de l'outil. Ça peut être en fonction des plateformes, soit vous êtes propriétaire finalement et la seule chose qui va se passer, c'est que la plateforme ne sera plus mise à jour, mais vos applis ne s'arrêteront pas de fonctionner pour autant. Donc, ça vous laissera du temps pour migrer sur une autre technologie. Ça peut être sur les plateformes qui génèrent cette fois-ci le code. Vous récupérez le code, comme nous, par exemple, Talent.

45:40 Ça génère du code Java. Le code Java, on fait ce qu'on veut. Il est stand-alone, on peut le récupérer. Alors certes, il n'est plus trop maintenable si demain Talent disparaît, mais le système d'information ne s'arrêtera pas de tourner pour autant. Donc, le risque est mesuré, il est anticipé. Et le fait aussi, il y a un avantage quand même pour une DSI de notre taille à se concentrer sur une technolo-code et pas plusieurs, ça reste la montée en compétence des équipes. Alors, même si on ne fait plus le dev interne, on maîtrise, nos chefs de projet maîtrisent la technologie. Il commence à avoir des vrais réflexes sur comment fonctionne le développement d'une appli. Et de ne pas s'éparpiller sur trop d'outils, je trouve que c'est quand même intéressant quand on essaie de rationaliser des coûts et des compétences. Donc, bien sûr, il y a un risque, mais je pense, comme tout projet informatique, Il faut l'anticiper le plus tôt possible et voir ce qu'on peut mettre en face en termes de récupération de données, de réversibilité et d'achat de licences et d'outils si vous avez peur de la location.

46:45 Du système locatif. Je vais rebondir. Merci Nicolas pour ta réponse. Je vais rebondir parce qu'il y a une question que j'avais en tête, qui n'est pas dans le chat, et qui est peut-être un peu plus... Tu parles justement de la stratégie de mise en place de la plateforme. On n'a pas trop abordé justement quels avaient été vos... Vos critères de choix, la façon, pourquoi est-ce que vous avez choisi une plateforme low-code, on a parlé du contexte, on a parlé des avantages, mais... Je vais faire peut-être un peu de couverture des avantages. Alexandra, je pense qu'il y a dessus. Alexandra a plus de choses que moi à dire, mais... Vous l'avez dit, Alexandra, comment c'est? Oui, j'avais proposé. Non, mais vas-y, tu peux. Peut-être qu'on peut orienter ça, comme on arrive, je vois, sur la fin du timing, sur quels seraient les conseils qu'on pourrait donner à quelqu'un qui veut se lancer dans le conseil. Un conseil, mais moi, que je prends pour tout choix d'outil, c'est tester-le avant.

47:47 Vous n'engagez pas dans des plans à 4 ans sans avoir au moins fait un POC, un pilote, tester la technologie, tester le prestataire aussi, la réactivité du prestataire, parce que c'est tout aussi important que l'outil parfois. Enfin, l'éditeur, quand j'entends prestataire, c'est l'éditeur. Donc, ça se teste, tout ça, et seulement une fois que vous avez validé quelque chose qui tourne, là, je pense que vous avez déjà beaucoup plus de billes pour être serein et aller présenter ça à une direction générale ou en tout cas mettre ça dans les éléments stratégiques de votre entreprise. Ensuite, nous, notre choix, c'était clair, c'était réduction des coûts, plus d'efficience dans le déploiement de nos applications, donc aller plus vite sur la mise en prod de nos applications. Et puis aussi, on n'en a pas parlé, c'est essayer de réduire le shadow IT. L'idée aussi qu'on a derrière, c'est de réinvestir le temps qu'on gagne. Sur les développements des applications institutionnelles pour essayer demain de le réinvestir avec une équipe interne sur des développements de petites applications et limiter le shadow IT. Voilà, dans les grandes lignes, j'oublie peut-être quelque chose, je vais laisser Alexandra répondre et puis je reviendrai dessus.

48:52 J'aimerais identifier aussi des avantages communs que tu viens d'évoquer. Mais moi, si j'avais un conseil à donner, c'est vraiment de fonctionner en mode agile. dans le cadre de la mise en place d'une plateforme low-code, parce que c'est une plateforme agile. Pour nous, ça a été un win-win. Clairement. Et puis, moi, ce que je trouve, c'est que ces plateformes-là sont hyper agiles. Elles consomment très peu de temps, finalement, aux équipes projet en temps. Dans mes équipes, sur des phases d'évolution, pour moi, il y a un gain de productivité qui est énorme, qui est apporté. Et nous, on était vraiment, on est focus time to market. Donc, il faut délivrer rapidement, répondre rapidement aux clients. Donc, c'était vraiment dans ce souci de gagner de la productivité pour les équipes. Après, l'évolutivité, c'est clair. Enfin, moi, la technique, je ne sais pas.

49:53 Mais en tout cas, moi, ce que je vois en termes métier, c'est qu'au vu des difficultés, des retours, d'expérience que j'ai eue sur l'intégration progicielle, grâce à cette technologie, en fait, on s'affranchit de l'obsolescence technologique plutôt du parc applicatif existant dans lequel l'applicatif va se sourcer. Et ça, pour nous, c'est une sécurité déjà. Et puis après, comme tu l'as dit, Nicolas, après la plateforme s'arrête, on l'a, OK, elle n'évoluera plus. Mais après, on fera différents scénarios de choix pour assurer la continuité. Et c'est aussi, pour moi, un gage de succès, c'est aussi la simplicité, en fait, à appréhender par un métier, cette plateforme, à pouvoir l'administrer. En fait, on a l'impression qu'il n'y a pas d'informatique derrière. C'est quelque chose qui est largement paramétrable et qui est simple, en fait, comme ce sont des objets métiers, dans l'application, ce sont des objets qui parlent à quelqu'un qui est dans le métier.

50:54 Donc, je trouve assez user-friendly, en fait, ces technologies. Voilà, donc moi, j'y trouve beaucoup d'avantages. Après, sur la réversibilité, à date, nous, ça va faire deux ans. À date, pour l'instant, je n'ai pas identifié de risque. Mais après, moi, je laisse ça à faire aux experts techniques. Je pense qu'il y a toujours un risque, mais effectivement, quand on l'anticipe et quand il est mesuré, voilà, c'est… C'est comme tout, ça se gère un risque, ça se gère, ça se provisionne. Pour nous, il n'a pas été bloquant, en tout cas. Et je rajoute juste un petit truc, ça c'est une nuance que j'ai. au sein de la NSM, certes, c'est effectivement beaucoup plus efficace, mais attention à la combinaison low-code méthode agile, si vous cadrez mal, si vous n'avez pas l'habitude de cadrer et de travailler en méthode agile, c'est justement parce que les utilisateurs, les MOA, vont voir un tas de choses, un tas de possibilités s'offrir à eux en travaillant méthode agile. On a vite fait de dériver finalement. Je veux ça en plus, je veux une fonctionnalité supplémentaire.

51:56 Donc, il faut juste prendre garde à ça et ça se passe très bien. Mais il faut être clair dès le démarrage sur le nombre de sprints alloués au projet, son budget, son planning et faire le maximum pour le respecter. Et le contenu du backlog, tout à fait. Tout à fait, parce qu'on en a encore dans le backlog. Mais bon… Il y en a toujours en fait. Mais c'est très… On vit tout le temps. Il y a une émulation finalement. Quand on travaillait à l'époque en méthode agile et en spécifique, les gens faisaient leur spec, ils faisaient leur maquette. Et puis, quelques mois plus tard, ils voyaient le résultat. Et puis là, soit la déception, soit une demi-satisfaction. Alors que là, ils voient évoluer l'appli. Ça leur donne plein d'idées en cours de route. Et c'est là qu'il faut être vigilant. Mais c'est un tout petit, ce n'est même pas un désavantage, au contraire, c'est le rançon du succès de ce type de plateforme. C'est ça. Moi, je vais juste faire une petite remarque, en fait, parce que si j'ai un conseil à donner, tu nous as demandé si on a des conseils à donner. En fait, nous, on avait intégré l'UX dès le départ, mais on était…

53:00 très vite rattrapé en fait par lui qui en fait suscitait un petit peu de rejet par le métier donc on a intégré dans l'équipe un ergonomes et c'est vrai que sur la plateforme ça lui a fait un réel apport en fait et ça a engagé en fait davantage d'utilisateurs sur la plateforme. Parce que ce n'est pas tant les objets métiers. Il y a aussi, il ne faut pas négliger l'UX et l'UI dans le projet. Très bien. Merci à tous les deux pour tous ces conseils. Je vois qu'il y a encore beaucoup de questions. Malheureusement, on arrive à la fin de cette heure de meet-up. Je vous rappelle, enfin, je me suis mis à monter sur scène, mais en attendant, je vous rappelle qu'on va se retrouver sur les différentes tables juste après. Donc, vous pourrez vous poser vos questions plus ou moins techniques à Nicolas ou à Alexandra ou même à moi-même, si vous voulez, puisque je ne parlerai pas de simplicité ou de stratégie d'entreprise, mais peut-être plutôt du low-code en général, si vous avez des questions. Et puis, je vais laisser la parole à Noémie.

54:01 Merci à tous pour vos questions. Merci Nicolas, merci Alexandra.