← BibliothèqueToutes les vidéos
Meetup Tech.Rocks
Ce que le low-code peut changer pour vous
- Cornel Fatulescu (Chief Platform Officer, Pentalog)
- Christophe Charles (Head of Low-code, Pentalog)
- Thomas Villaren (Low-code Architect, Payfit)
- Marie Terrier (CTO, Yelda.ai) — animation
- Tommy Dessine — illustrations en direct
Meetup Tech.Rocks · 17 novembre 2020 · 65 min · en français
Résumé
Et vous, où en êtes-vous avec le low-code ? Vous en avez sûrement déjà entendu parler, mais avez-vous intégré ces technologies à votre quotidien ? Ce meetup Tech.Rocks revient sur les bases de cette approche : - Qu'implique le low-code pour la restructuration de votre SI ? - Quels bénéfices et opportunités crée-t-il ? - Comment s'y mettre ? Quels pièges éviter et quelles bonnes pratiques mettre en place ? Cornel Fatulescu aborde des cas concrets de besoins au sein du groupe Pentalog, complétés par le retour d'expérience de Christophe Charles, Head of low-code de Pentalog. Thomas Villaren (Payfit) revient sur son rôle de R&D Lead chez Generative Objects, où il a vécu l'évolution du low-code : d'un produit d'abord destiné aux développeurs à son pivot vers d'autres utilisateurs. Débats suivis de tables rondes en seconde partie. Meetup organisé en partenariat avec Pentalog.
Summary
So where do you stand with low-code? You have probably heard about it, but have you already made these technologies part of your daily work? This Tech.Rocks meetup goes back to the basics of this approach: - What does low-code mean for restructuring your information system? - What benefits and opportunities does it create? - How do you get started? Which pitfalls should you avoid and which best practices should you adopt? Cornel Fatulescu discusses concrete needs within the Pentalog group, followed by lessons learned from Christophe Charles, Head of Low-code at Pentalog. Thomas Villaren (Payfit) looks back on his time as R&D Lead at Generative Objects, where he witnessed the evolution of low-code: from a product first aimed at developers to its pivot towards other users. Discussion followed by round tables in the second part. Meetup organised in partnership with Pentalog.
Thèmes : Architecture & développement
Transcript complet
Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.
Bonjour à tous, je m'appelle Marie Terrier et je suis la CTO de Yelda et j'animerai ce meet-up aujourd'hui. Rapidement, Yelda, qu'est-ce que c'est? C'est une plateforme SaaS qui permet de déployer des assistants vocaux, donc autrement dit des chatbots à la voix, qui sont pré-entraînés et customisés. ou sur un site web. Mais bon, ce n'est pas moi le sujet aujourd'hui. Donc, pour démarrer ce meet-up, je vais maintenant faire monter sur scène Christophe Charles, qui est Head of Low-Code chez Pentalog, et Cornel Fatulescu, Chief Platform Officer chez Pentalog, qui vont nous faire tout d'abord un état des lieux du low-code avec quelques chiffres. Suivi d'un retour d'expérience du low-code chez Pentalog et de l'expérience avec PowerApps. Donc, à vous de jouer, messieurs. Merci Marie. Très content d'être avec vous aujourd'hui. Comme l'a dit Marie, l'idée c'est qu'on vous partage un peu le retour de ce qu'on a pu faire en low-code ces derniers mois et à quel point ça a pu changer pas mal de choses chez nous et la vision qu'on a pour la suite.
Et avant de laisser la parole à Cornel, vraiment sur cette partie-là, Je vais vous dire deux, trois mots rapidement sur qui on est. Et je ne sais pas si vous avez vu, mais on a envoyé un survey il y a quelques jours. Et donc, j'ai fait un retour sur les tendances et ce que la communauté sait et a déjà fait en low code, histoire de poser un peu le contexte. Donc déjà, Pentalog, nous, on est spécialisé dans la construction d'équipes agiles, pluridisciplinaires, au service du produit de nos clients. Historiquement basé surtout en Europe, mais aujourd'hui, on a implanté des centres de service dans les différents continents. Donc, on est présent en Amérique, en Europe et en Asie. Et l'idée, c'est depuis toujours d'avoir développé à fond notre ADN agile pour s'adapter au mieux aux contraintes du produit de nos clients et de l'organisation de nos clients. Et de venir apporter juste les ressources nécessaires en plus dans une logique d'intégration la plus fluide possible. Aujourd'hui, Pentalog, c'est essentiellement du développement, mais c'est aussi du DevOps, de la sécurité, des QA, de l'UX, de l'UI, du Product Owner, du Growth, du Marketing,
beaucoup de choses qui gravitent autour du développement. On travaille beaucoup avec des gros groupes comme Adidas, TripAdvisor, Rakuten, New York Times par exemple, et aussi beaucoup avec des startups. Et encore plus, moi je suis basé à Lyon dans la partie Pentalog Innovation Factory, et on a une ADN très startup sur tout le réseau lyonnais. Petite parenthèse aussi sur un service de la plateforme Pentalog qui peut peut-être vous intéresser, c'est la plateforme Skill Value qui permet de faire de l'assessment et de la recherche de profils freelancers. Aujourd'hui sur la plateforme, on a 30 000 freelancers évalués et 400 000 enregistrés. Bon bref, voilà, tout ça c'est sur Pentalog. Aujourd'hui on va parler de low-code. Pourquoi est-ce qu'on parle de low-code? Toujours dans cette idée d'ADN agile. On a voulu tester un peu les différentes plateformes qui se lancent.
On a voulu se restructurer aussi en fonction de ça et ça nous a permis d'accélérer sur beaucoup de points et notamment aussi dans la situation du Covid. Et c'est sur cette partie-là qu'on voulait revenir avec Cornel. En introduction, peut-être qu'on peut rappeler rapidement aussi ce que c'est que le no-code et le low-code, parce que ça veut dire un peu beaucoup de choses, donc peut-être pour resituer un peu de quoi on parle aujourd'hui. L'idée, c'est peut-être le no-code, ça va être le plus simple à comprendre, c'est vraiment un... Une philosophie ou des frameworks qui te permettent de créer des applications à base de drag and drop et d'outils visuels sans jamais écrire la moindre ligne de code. Ça peut être très puissant pour créer des petits protos orientés plutôt POC pour des utilisateurs, dans un contexte où on n'a pas forcément besoin d'écrire des règles métiers spécifiques ou d'avoir une UI spécifique ou autre. Et un des leaders du marché aujourd'hui, c'est Bubble.
Il y a pas mal de startups qui s'en servent pour créer des petites apps web. Ça commence à être vraiment poussé comme outil. Et ça s'adresse aussi beaucoup à ce qu'on appelle le citizen developer, c'est-à-dire la personne qui va vouloir créer une app sans forcément avoir les compétences techniques pour ça. Ensuite, le low-code, ça englobe aussi beaucoup de choses. Nous, aujourd'hui, on va surtout se concentrer sur la philosophie et les plateformes qui sont lancées par les différents acteurs du marché. L'idée, c'est d'avoir un framework, encore une fois, comme une grosse boîte à outils qui nous permettent d'accélérer sur certaines problématiques techniques récurrentes, que ce soit dans le développement, mais aussi dans la partie déploiement, dans le DevOps, dans la sécurité. Et c'est de pouvoir utiliser cette boîte à outils pour accélérer les itérations et accélérer finalement la réflexion autour du produit et des métiers et un peu moins autour de la technique. J'espère que c'était clair.
Si jamais vous avez des questions sur ces deux thématiques, on y reviendra après dans les questions-réponses. N'hésitez pas à reposer quelques questions. Dans les acteurs principaux du low-code, on retrouve beaucoup Microsoft depuis plusieurs mois qui a sorti la plateforme Power Apps. On retrouve des acteurs historiques comme Mendix qui sont là depuis longtemps, Outsystem, Amazon se lance aussi dans la course. Donc bref, il y a beaucoup d'acteurs importants aujourd'hui et on voit que le sujet... Montent justement en importance dans ces gros acteurs. Ok, maintenant sur le survey que je vous ai envoyé à la communauté la fin de semaine dernière. C'était assez intéressant de voir les différentes réponses qu'on a eues. Globalement, les gens qui ont répondu à ce survey avaient une impression d'être à peu près, de connaître le sujet, on va dire, à 6 sur 10. Donc, le sujet intéresse les gens, ils se renseignent dessus.
Ce n'est pas encore un sujet sur lequel on a beaucoup d'expertise globalement chez tous les CTO, mais c'est un sujet quand même qui intéresse beaucoup de personnes. Et sur les types de besoins qui ressortaient le plus, beaucoup mentionnaient la création de POC ou de MVP. Alors c'est vrai que ça peut être adapté et on a vu aussi plein d'autres usages justement dans la plateforme Pentalog et qu'on va partager. Et il y a aussi cette notion d'accélération, d'itération plus rapide et de croissance. C'était assez intéressant aussi, j'avais mis une question sur les différentes technos et pour les personnes qui avaient créé une app en low-code, quelle plateforme ils avaient utilisé. Et dans cette question, j'avais mis, je crois, neuf des leaders un peu du marché et une case autre. 60% des gens avaient coché la case autre. Donc ça montre à quel point aujourd'hui le low-code c'est très, on va dire, diversifié. Il y a beaucoup de types de plateformes différentes.
Il y a aussi des plateformes internes pour des besoins internes. Donc quand on parle de low-code, ça englobe vraiment beaucoup de choses. Donc nous, on va se concentrer vraiment sur une certaine vision du low-code. J'ai fait un petit stop pour lire le super dessin de Tommy. Ensuite, sur la durée, et je vais finir sur la notion de durée, j'avais posé deux questions. La durée théorique pour vous pour la création d'un POC en low-code et la durée théorique pour vous de la création d'un MVP en low-code. C'est intéressant, ça va permettre justement de mettre un peu en comparaison avec des durées plus classiques de MVP qu'on peut connaître. Sur les réponses, sur la partie POC, dans tous les cas, c'était moins d'une semaine. Il y avait beaucoup de réponses qui étaient à un à deux jours et beaucoup de réponses qui étaient à un à deux jours. Moins d'une semaine. Donc ça, c'est vraiment une donnée qui montre à quel point c'est rapide et efficace de tester une idée avec ce type de techno.
Et sur le MVP, sur un produit un peu plus stable et qui peut être lancé, on est entre deux et quatre semaines. Donc ça reste des cycles de développement super intéressants pour pouvoir itérer, tester et réitérer ensuite. J'espère que cette petite intro est à peu près claire sur les chiffres clés. Je pourrais repartager les chiffres avec la communauté si vous le souhaitez. Et l'idée, c'était de reposer un peu le contexte avant qu'Ornel rentre plus dans le détail sur notre utilisation aujourd'hui du low-code. J'en profite de faire une petite parenthèse encore sur les tables rondes, parce que c'est vrai qu'on a un peu poussé le principe des tables rondes plus loin qu'habituellement dans les meetups Tech.Rocks. On a vraiment donné des thématiques sur chaque table ronde, vous pouvez les retrouver dans le chat, on vient de les reposter. Et il y aura une personne dans chaque table ronde de Pentalog qui a travaillé avec le low-code. Il y aura des tables rondes plus orientées sur des retours d'expérience, sur des développeurs low-code qui ont bossé sur cette app.
Si vous avez des questions, n'hésitez pas. Donc ce sera des tables rondes peut-être plus orientées techniques. Il y a des tables rondes plus orientées stratégie. Il y aura une table ronde avec... Cornel sur justement la suite de son discours et de sa vision autour du low-code. Il y a une table ronde avec moi, plus autour de l'offre low-code chez Pentalog. Il y a différents types de tables rondes. N'hésitez pas à venir nous rejoindre sur une de ces tables rondes à la fin du meet-up. Voilà, Cornel à toi. Alors, attends, Marie, tu as une question? On a déjà une première question. Donc, est-ce qu'il y a un service, site, app, connu qui utilise le low-code que tu connaîtrais par là? Je connais pas mal de startups qui ont créé un produit avec Bubble. Je ne connais pas forcément énormément de gros acteurs qui ont dans leur ADN le low-code, mais souvent c'est aussi utilisé en background, donc on ne s'en rend pas forcément compte.
Typiquement, on le verra tout à l'heure avec Thomas de Payfit sur comment est-ce qu'un outil comme Payfit utilise du low-code pour pouvoir créer ses nouveautés dans le produit. Je crois que la SNCF a fait pas mal de choses pour les gens qui sont sur le terrain pour rentrer de la data, pour éviter des erreurs de saisie. Ça ne m'étonne pas, puisque c'est vraiment dans l'idée d'automatiser des flux de données et de simplifier la gestion des flux, ajouter des règles métiers dans ces flux. Donc, ça paraît très cohérent. Et juste une deuxième petite avant de laisser la main à Cornel. Quels outils utilisez-vous pour garantir la qualité du code par rapport aux outils low-code. Alors, ça va pas mal dépendre de la plateforme low-code que tu vas utiliser. Chaque plateforme arrive souvent avec sa philosophie et sa suite d'outils adaptés à chaque plateforme. Par contre, il y a certaines règles qui restent toujours valables pour d'autres types de développement, c'est-à-dire tout ce qui est code review ou indicateur de qualité un peu classique.
C'est encore une réponse un peu large, mais dans l'idée, chaque plateforme a sa suite d'indicateurs de qualité. Chez nous, on utilise beaucoup PowerApps, mais il y a aussi d'autres plateformes avec d'autres outils. Mais dans la suite de PowerApps, car je vais enchaîner sur ça, tout est intégré. Ça veut dire qu'à la volée, tu as l'analyse statique de code, tu as les erreurs, tout est intégré dans l'environnement de la plateforme. Donc, dès que tu changes quelque chose, tu vois les très, très belles assistances et tout ce qu'il te faut. Mais ce n'est pas comme tu travailles avec du sonar. Ce n'est pas la même chose. Je vais expliquer pourquoi. Ok, mais on va te laisser la main alors, Cornel, et je n'hésiterai pas à t'interrompre si on a des questions spécifiques. Super. Oui, tu peux partager ton coin. Donc, déjà, merci d'être là.
Je vais parler du low-code avec PowerApps. Et je me suis dit, il faut que ça soit centré pour les Chief Technology Officers. Donc, j'ai pensé, s'il faut reprendre tout ça de départ, quelles sont les questions que j'allais me poser, qu'est-ce qui sera plus utile. Et pour faire cela, comme il y a beaucoup de subjectivité dans ce que je veux dire, car quand on parle de vision, quand on parle de stratégie, il y a toujours une subjectivité. Et pour éviter des débats un peu... Religieuse du terme, je vais expliquer un peu le contexte et pourquoi on est là, pourquoi on parle de low-code à Pentalog, pourquoi on fait du PowerApps. Et je pense que c'est essentiel. D'abord pour nous, et je pense que pour la plupart des équipes, des équipes IT, il y a une limite de backlog.
Donc, on ne peut pas tout traiter. Et donc, ça génère des frustrations. Leurs problèmes sont toujours importants, mais ça ne rentre jamais. Voilà, donc on cherche... de possibilités. On a même cherché à innover, on regarde tout le temps, qu'est-ce qu'on peut faire pour qu'on intègre plus de demandes tout en gardant le contrôle de ce qu'on fait. Et bien évidemment, dans une stratégie cohérente de digitalisation de la plateforme. Après, on a du legacy. Je pense que tout le monde en a, un tout petit peu au moins. Mais nous, on avait quelques éléments, quelques monolithes legacy, donc standard, un peu trop de responsabilités pour une appli. On cherchait comment travailler ces appuis-là. Et une option qui s'avère être la bonne, car on prouve que ça fonctionne bien, c'est de découper des macro-fonctionnalités de ces monolithes dans des micro-monolithes.
Et d'abord, on garde la même... Base de données pour point d'intégration de données et après on split et après tout est découpé. Voilà donc c'est un peu notre stratégie grosso modo. Les coordonnées sont toujours les plus mal chaussées. Nous on est un groupe 1200 employés, s'il y a quelque chose qu'on fait c'est du product, du coding et quand on regarde ces ces monolithes et ce legacy, je me suis dit, il faut absolument que ça change. Il faut absolument que ça change. Et voilà, donc l'HoloCode fait partie de cette stratégie de ça change. Bien évidemment, pour accélérer le développement, tout le monde cherche des opportunités là-dessus. Pour être mature sur Extreme Programming, Continuous Deployment, c'est quand même une art et peu importe ta séniorité organisationnelle, il y a quand même un schéma.
Quand on a des instruments pour... Construire des miroirs sur notre produit, on les appelle des maturity models, on regarde nos produits, des points de sécurité, infrastructure DevOps, données, architecture, il y a plusieurs perspectives. Et quand on regarde tout au tout début de ton schéma, tu n'es pas suffisant sur l'infrastructure DevOps. Donc, qu'est-ce qu'on peut faire pour diminuer la complexité, pour diminuer les choix aussi, pour aller plus vite et des fois ne plus prendre la tête avec ce genre de sujet. Sécurité, DevOps, gestion de données, questions de mécanique, qui nous permettent quand même de rester en contrôle des données. Même avoir de meilleurs contrôles sur les accès de données. Je vais enchaîner plus tard. Après, il y a tout un changement. On a vu COVID, Collaboration Platform as a Service, et je ne sais pas à quel point tout le monde
se rend compte du fait que ça vient avec un nouveau modèle de App Store où tout le monde est dans cette plateforme-là et il y a des applis dedans. Et ce n'est pas très intéressant et faire les gens sortir de Teams ou Slack, pourquoi ne pas faire tout là, tout, dans les limites raisonnables. Donc, toutes ces applications très utiles. pour les collègues, pour nos employés, productivité, doivent être là. Et c'est quelque part un changement important, à mon avis, dans l'industrie. Après, on a amené ce nouvel concept dans notre vision qui est programmable companies. Notre vision est que les sociétés vont se transformer et ceux qui vont se transformer sont les sociétés programmables. Ça veut dire que complètement digitalisées. Donc, dans la société, peu importe ce qui se passe, c'est un événement et il y a des actions et des déclencheurs qu'on peut programmer.
Ce n'est pas le but de faire une séance là-dessus, même si j'aimerais bien parler pendant des heures. Et dernière chose qui est un peu conséquence de tout ce qui est déjà dit, c'est le self-service. Donc pour y arriver, on a dit dans notre vision, et c'était déjà dans notre roadmap de l'année passée, Il faut amener cette capacité self-service, self-service BI, self-service development, des raisons que je viens déjà d'itérer. Et le low-code fait partie de cette démarche de self-service. Tu arrives à te construire toi-même comme tu fais avec self-service BI, avec des outils de tableau, où tu arrives à te faire tes propres dashboards, pareil avec des applis. Tu arrives à faire tes propres applis. Qu'est-ce que ça donne quelque part ? Dans le paysage de plusieurs choses qu'on peut faire dans le self-service, et je vais insister un peu là-dessus car c'est important, et surtout pour nous, on a des citizen developers et chez nous, on se dit, voilà, citizen developers, c'est des personnes qui peuvent être techniques ou pas, mais qui veulent automatiser quelque chose, qui peuvent faire des interfaces.
On doit avoir le contrôle sur les données, sécurité et tout. Donc, il y a quand même... des choix qui définissent leur spectre d'autonomie. Et par default, c'est PowerApps, SharePoint, Power Automate, tout autour de Teams, Office. Et je mets à plusieurs reprises, je mets Data Catalog, car c'est quand même essentiel. Vous allez voir, s'il y a quelque chose qui va décoller, c'est Data Stewardship, l'administration des données. Et donc, pour cela, il faut mieux faire documentation des données, Data Catalog, tout ça. Et on a aussi des citizen data analysts, donc ceux qui font du tableau. L'année prochaine, très probablement, on va rajouter Power BI, data catalog toujours essentiel là-dessus. On a des professional devs, donc des personnes, des développeurs qui ne font pas partie de l'équipe de product où nous avons utilisé... PowerApps également. Et eux peuvent faire avec du PowerApps, mais ils peuvent faire du custom development.
Et donc, dans cette stratégie, bien évidemment, il faut faire du API, du DevPortal, il faut avoir des services de stockage. Ce qui change chez nous, c'est, on a dit, plus d'autres types de stockage que ce qui est derrière des API, Data Services, SharePoint, voilà. Donc, il y a des services derrière les coulisses. Mais c'est quelque chose d'assez fondamental dans notre vision. Si tu veux vraiment faire quelque chose, c'est un problème que tu as adressé et c'est important pour toi. Et si nous, on n'a pas de place dans le backlog, fais-le. Mais nous, on doit rester en contrôle de ce qui se passe. Donc, ça veut dire que ce que tu fais ne doit pas exposer la société au risque. Voilà, donc c'est un peu la philosophie. Et il nous reste, donc avec tout ça, les premières trois colonnes-là, on estime que jusqu'en 2023, la plupart des applications seront faites via self-service development.
Et nous, on va se concentrer sur les données, sur les services derrière les coulisses et on se fait des choix aussi là-dessus. On a dit by default, manage services pour accélérer, serverless. Voilà, il y a toute une liste de priorités. Et on est très content de faire ce choix. Je donne juste un exemple de choix d'insolence pour avoir confiance. Si vous voulez faire du Elasticsearch ou un Elasticsearch Managed, où on a fait Azure Search, les problématiques DevOps que vous avez si vous faites tout vous-même, C'est des projets entiers des fois pour bien le faire. Encryption on rest, ce genre de choses. Alors que quand on utilise des services managed, on l'active, on fait sa fonction et on fait juste gaffe de ne pas... Et dans la partie front office, on fait toujours des applis, pas du low code pour l'instant, mais on cherche des options à faire du low code dans le B2C aussi.
Et surtout dans le front. On a vu déjà certaines options de PowerApps qu'on n'a pas utilisées pour faire ça. Ça amène à un autre modèle de pricing, je vais parler un peu plus tard. Donc, c'est possible, il y a des limites. Donc, tu ne peux pas faire n'importe quoi, c'est pour cela qu'on va trouver une autre option. Et aussi très important ici, nous, on va rajouter des options low-code dans la plateforme aussi, car on souhaite expérimenter avant qu'on propose au client. Donc là, par exemple, nous, on a fait du PowerApps de Microsoft Salesforce. Ce n'est pas suffisant. Il faut encore au moins une pour que nos clients, qui sont dans la zone de custom development, peuvent choisir des choses qui sont le plus appropriées dans le contexte. J'ai même un diapo sur comment choisir les plateformes de low-code. Donc, tout ce qui est en temps de vie, ça sert pour le contexte. J'en profite pour t'interrompre parce que là, tu parlais de limites et tu passais en revue un peu tous les domaines d'application du low-code.
Donc, on a une question de Julien Bénichoux qui est, quelles sont les limites du no low-code en matière d'application métier, en particulier sur des règles... de gestion complexe. Donc, tout d'abord, pour moi, no code est, car moi je vais parler plutôt de low code avec PowerApps, mais no code est restreint à des cas d'utilisation très spécifiques. Et je vais donner des exemples des limites qui font très, très mal, très, très mal. Si jamais avec du no-code, vous devrez faire, je vais prendre le chou. chose simple, de traitement de texte. De traitement de texte. Bon, faire ça avec du no-code, c'est la folie. Donc, un truc avec du code, un petit morceau de code, c'est un ligne de code. Faire un split, trouver des choses, un lambda expression, avec du no-code, voilà, c'est une expertise.
Et donc, tu vas vite dans des scénarios comme ça, et il faut faire très attention quand vous faites du no-code, à ce genre de limites. Est-ce que c'est vraiment du no-code, ou il y a quand même des possibilités à rajouter de morceaux de code, je ne sais pas, au moins un lambda function, ou major function sur Azure, ou de serverless, pour faire des traitements spécifiques, sinon vous trouvez vite les limites. Et pour moi, ça, c'est le plus important. Il y a même, si vous regardez, il y a des langages de développement. Qui existe aujourd'hui justement car les équipes IT souffrent de nos codes comme Ballerina. Regardez Ballerina pour le développement réseau. Leur essence quelque part est avec du local tu peux faire la même chose, tu peux faire des app et tout. Mais qui est-ce qu'on souffre? D'accord. Donc, voilà. Mais ça sort un peu du cadre de, j'espère que je ne sois pas trop, mais il y a des limites avec une code plus importante.
Donc, il faut avoir des cas d'usage. très spécifique et s'assurer avec du low-code. Peut-être que tu peux revenir sur le low-code et justement les capacités de réinjecter des règles métiers complexes plus facilement. Tu peux le répéter? Je disais, la question était pour le no-code et le low-code. Et pour l'instant, c'est vrai que tu as mis en avant les limites du no-code. Et je pense que c'est intéressant de rappeler, du coup, les possibilités, justement, des plateformes low-code sur les règles complexes. Sur PowerApps, il y a plusieurs types d'applications. Il y a des applis Canvas, il y a des applis model-driven. Et donc, quand on pense des objets métiers, entreprises à grande échelle, il faut choisir model driven. Et il y a toute une mécanique pour travailler avec ces objets, une expertise. Ça sort du data citizen dans la réalisation de ces objets.
Donc, il y a toujours l'équipe IT qui doit les penser, qui doit les construire et les mettre à disposition. Et après, les data citizens, les low coders qui sont moins techniques peuvent les réutiliser. Mais voilà, donc les plateformes low code viennent avec cette capacité by design. Ok ? Je pense que tu peux enchaîner. Voilà, pourquoi Power Platform? Car quand on parle de Power Apps, on parle du Power Platform qui est une suite de Microsoft. Donc, si vous regardez les études de Gardner Forrester, Microsoft sur Antop, sur Low Code et sur... BI, c'est le service BI Analytics. C'est très important chaque fois quand je fais des choix, je regarde d'abord d'ici, c'est le point de départ, et après j'ai choisi ce qui me va mieux, et j'enchaîne. Je ne savais pas exactement combien d'éléments je pouvais mettre de ces études ici, mais pour moi c'est le point de départ systématiquement.
Et de là, j'ai fait mes choix pour qualifier ce qui me vaut mieux. Et nous, on a choisi Power Platform. Des raisons qui tiennent aussi de notre contexte, notre partenariat avec Microsoft qui est imbattable au niveau prix, office, Azure, licence, tout. Ça fait que voilà. Et ça marche, on est très content. Mais si vous avez un stack technologique différent, Voilà. Il faut regarder dans notre angle. Donc PowerApps, c'est juste une solution. Ça vient d'un monde d'habitude avec Power Automate, qui tient aussi automatisation BPM, ça contient des robots process automation, très très puissante comme plateforme. Les deux viennent ensemble. Moi, je vais parler plutôt de Power Apps, mais derrière Power Apps, il y a aussi du Power Automate.
Power BI, à mon avis, je pense que c'est un truc où Microsoft a repositionné un produit très, très puissant. À mon avis et on le voit mais ça demande quand même une expertise pour faire du power bi comme sur tableau d'ailleurs tu commences vite à faire quelque chose mais tu veux faire quelque chose des choses sympas, bien, il faut apprendre. Donc, à mon avis, c'est moins sans formation, alors qu'avec PowerApps, tu peux commencer sans formation et à mon avis, tu y arrives à faire des choses simples, vite faites. Et Power Virtual Agent, c'est une nouvelle solution qui est apparue en fin d'année, si je me rappelle bien. D'ici, Power existe depuis des années. Mais Power Virtual Agent, c'est nouveau. Nous ne l'utilisons pas, on l'a testé. Le ticket d'entrée, c'était assez cher. Et on a trouvé une limite. On ne pouvait pas changer le modèle. De conversation, donc derrière Virtual Agents, il y a Language Understanding et on ne pouvait pas changer les identités.
Donc, on n'utilise pas, on utilise toujours Chatbot Framework et Luis. Voilà, juste pour expliquer un peu le contexte Power Platform. J'enchaîne sur Power Apps. Pourquoi? Qu'est-ce qu'on a fait sur PowerApps chez nous? Donc, on a fait plusieurs types d'applications. Une vingtaine depuis le Covid seulement. Donc, des applications en production avec un facteur de succès étonnant. Ces applications sont juste utilisées. Gestion des entretiens et des compétences. Donc, ça, c'est utilisé par une population d'environ 200 personnes. On a digitalisé un processus qui était plutôt Excel. Mais j'ai entendu à plusieurs reprises que Excel, le code est pour remplacer Excel. Ce n'est pas vrai. Low-code peut faire bien plus que remplacer Excel. Vous pouvez faire des choses que c'était impossible, à mon avis, avant. Mais c'est un cas où on a remplacé Excel pour évaluer les personnes.
Work from home, donc après Covid, notre politique était, on travaille tous by default chez nous, mais quand même indépendant du pays, il y a des contrats en légal, donc il faut faire des demandes, travailler chez toi, tout ça. Et toutes ces documentations, tous ces travails-là, donc il y a une appli pour ça, très élégant, très apprécié. J'ai aussi une diapo avec quelques captures d'écran après. One-on-one, donc management des objectifs personnels pour que nos middle management puissent faire des entretiens avec des équipes réguliers pour voir où ils sont, motivation, ce genre de choses. Une application très utilisée également. Legal policies, un excellent sujet d'automatisation où on a des legal terms sur les sites, mais pour le mettre en place, c'était quand même lourd et un processus manuel. Donc, on a dit, on va automatiser tout ça, on va mettre ce contenu dans les mains de Legal, on va faire une appli, eux font réviser le contenu, ils disent publish, et quand c'est publish, c'est sur tous les sites mis en ligne.
Donc, automatisation. Processus. Gestion des jobs, un autre exemple. On avait un site qu'on voulait clôturer, qui faisait ça, donc des jobs pour Pentalog. Tout ça, c'est géré dans une appli et c'est affiché où il faut, sur pentalog.com, sur d'autres. Gestion de production et prévisionnelle, très lourde comme application. Ça, c'est très intense en tant que processing. C'est à la Excel, très trabulaire et tout, beaucoup de calculs. Platform services, c'est pour digitaliser nos catalogues de services. Synonymes, ça, c'est un sujet technique. Il y a très peu d'utilisateurs, mais on avait besoin des synonymes. Donc, quelque part, on a des glossaires, React, ça veut dire React.js, ça veut dire React.js, ce genre de choses, et le glossaire de technologie chez nous. Catalogue des prix, staffing, beaucoup d'applications. L'espace ne nous permettra pas d'aller dans tous ces détails. C'était vachement dur à choisir des écrans qui ne vont pas montrer quelque chose de personnel ou des données personnelles.
Et donc, j'ai choisi quelque chose qui est un peu neutre. Mais ça peut être très clean, ça peut être très sympa comme interface avec Power Apps. Et ça peut être très moche. Ça, c'est la gestion des synonymes, car on a voulu faire quelque chose vite. Et ça marche pour gérer des... Synonyme et quand notre pipeline de données derrière les coulisses fait tout ce qu'il faut pour identifier des compétences, ce genre de choses, on applique ces synonymes un peu partout. Je mets un exemple sur ça. C'était la seule application que j'ai pu vous montrer sans montrer quelque chose de trop confidentiel. Montrer un cas pratique sur ça. Donc, nous, on a un search sur le site et Si je souhaite chercher Amazon, je trouve des choses. Et cette liste, ça va juste enrichir.
Raison n'est pas. Ah, voilà. Donc, Amazon. Mais si je cherche JJJJJ, il n'y a rien. Évidemment qu'il n'y a rien. Et comment on gère tout ça? Moi, je peux aller sur Amazon. Donc ça, c'est l'appli, c'est du low cost. Je vais dire, je vais rajouter JJJ. Je vais faire ça. Donc, il y a le synonyme qui est rajouté à Amazon. Je vais publish. Et tout ça, voilà, ça c'est un autre type de low-code, mais c'est du low-code de transformation des données sur Azure Data Factory d'ailleurs. Et maintenant, quand on va regarder, je cherche autre chose, Java. Amazon. Voilà, donc Amazon, et si je cherche GGG,
Voilà, GGG, maintenant c'est synonyme avec Amazon. Ce qui est très intéressant, donc une petite automatisation de ce genre. Et donc, dès qu'on trouve que les utilisateurs ne trouvent pas quelque chose, on rajoute dans les synonymes et tout ça. J'espère que ça, c'est... C'était clair pour vous? Quelques chiffres clairs. Donc, depuis COVID, 20 nouvelles applications, 5 applications de refonte, 5 applications très techniques comme les synonymes ou legal statements ou des choses comme ça qui n'ont pas beaucoup d'utilisateurs. On ne va pas revoir les legal statements chaque semaine. Deux applications très, très utilisées, donc ça veut dire tous les utilisateurs du groupe, très belles réussites, très appréciées comme applications. Ce sont aussi les applications les plus belles. Le reste des applications font environ entre 20 et 40 utilisateurs par jour.
Et certaines... application demande un compte payant pour les utilisateurs. Et c'est là où il faut faire gaffe avec PowerApps. Vous pouvez faire plein de trucs avec ce qui vient gratuit avec Office Teams. Mais il y a des connecteurs payants, premium. Et pour cela, il faut des licences. Il y a deux types de licences. Des licences à une appli par utilisateur et des licences, donc ce qui est L1 marqué ici, et L2, appli non limitée par utilisateur. Et nous, on est à 50 comptes payantes. La plupart, la moitié sur d'un type. Et on va passer vers 100 licences utilisateurs applis payantes et 50 licences utilisateurs non limitées à applis.
Et enfin, T2, l'année prochaine, on va faire 300 respectivement, 150. Tout en gardant le dev classique, tout ce qui est derrière les coulisses, les services donnés et tout, ça reste vraiment une autre époque car on peut vraiment se concentrer sur ce qu'on n'arrivait pas à faire. Quelques conseils. Si vous faites du Power Apps, allez sur SharePoint directement. Très sophistiqué comme outil, excellent, ça facilite les choses. Cherchez à vous intégrer avec Teams, Active Directory, Office. Si vous réutilisez les données gérées par les applis faits avec du PowerApps, il faut quand même un minimum de compétences pour la personne qui développe. Donc, il faut comprendre un minimum de choses comme structurer les données, forme de normalisation, ce genre de choses. Ce n'est pas leur formation, mais c'est important. On a trouvé des limites là-dessus. Si ce n'est pas quelque chose d'intégrer dans les pipelines de données ou des choses comme ça, il faut laisser faire.
De toute façon, vous avez un contrôle total sur tout ce qui est donné, géré avec ces applis, sur le storage. Data stewardship, c'est l'activité qui a décollé. On avait du mal à le faire. Là, c'est consistant. Surtout avec ces nombreuses applis, vous imaginez l'administration qu'on doit faire et tout ce qui est autour de tout ça. Désolé de te couper, je te fais juste un petit point timing. Je vois qu'il y a 44. Je crois qu'on laisse la main à Thomas dans 2-3 minutes. Donc, on peut voir pour l'essentiel. Ok, alignement sur les UX, nous on trouve, c'est maintenant qu'on fait le standard pour mieux industrialiser. Quelques exemples de limites, PowerApps, les environnements, par exemple, base de données, tu ne peux pas changer le nom de base de données entre multiples environnements, mais si la base de données de test a un autre nom, c'est juste un limite.
Je laisse ça ici. Et j'ai raté Single Point of Failure. Vous avez vu ce qui s'est passé cette semaine avec Microsoft. Je pense que c'est des limites importantes. Après, c'est une question de vision. Et à mon avis, je vous ai parlé déjà de Programmer Companies. C'est quelque chose, à mon avis, il faut regarder. Low-code, c'est juste un outil parmi une boîte d'outils. Il y a du deep code, ça s'extende, ça ne remplacera jamais le code, ni le deep code. Et donc, c'est juste un outil. Il faut bien lui donner le cadre. Il faut avoir des priorités claires sur... Qu'est-ce qu'on fait avec nos codes, low codes, main services et tout ça? On est dans un monde où on est data-driven technology à la place de technology-driven data. Donc, ça shift, ça change tout ça. De nouveaux canaux. canaux d'appli, donc plateforme collaborative, et il faut favoriser tout le temps la simplicité dans les choix techniques. Et si vous ne voulez pas de low code, le code vous voudra.
Ça veut dire qu'il rentrera dans votre entreprise. On voit déjà ça dans certains clients où l'équipe de marketing, pour accélérer la digitalisation de ce qu'ils font, ils vont faire un contrat séparé, ils vont aller sur ce genre de plateforme, ils feront les applis, ça marche, et le système d'information n'est plus en contrôle. Donc, à mon avis, il faut embrasser le low code. Pour des nouvelles règles, contrôle total sur les données, low-code steward, versionnage de données. Et pour chez nous, il n'y a pas d'application publiée sans avoir les données documentées. Pour choisir les plateformes, je viens de dire, regardez Gartner. C'est comme ça que j'ai fait. J'ai laissé ici quelques consignes. Le prix n'est pas négligeable. Ça fait un ou deux personnes en ETP, en dépendant de la plateforme. Donc, c'est comme ça que vous pouvez regarder comme coût mensuel. Et il faut voir si ça va pour vous ou pas.
Par du marché, il faut toujours, ma philosophie est d'utiliser ce qui est déjà testé. J'ai plein de trucs à tester. Je ne vais pas tester les plateformes low-code pour voir si ça marche. Donc, j'aille sur ce qui est le plus, qui a meilleure réputation. Voilà ce que j'ai voulu vous présenter. Je ne sais pas s'il nous reste encore. Oui, non. Mais là, ça va faire un peu de temps. Donc, merci beaucoup. On a appris vachement de choses sur les Power Acts, notamment. Donc, je voulais dire au public de continuer à poser des questions pour tout ce qui est relatif au low-code en général. Du coup, Thomas pourra y répondre dans sa partie. Et pour tout ce qui est PowerApps, en fait, continuez de poser des questions dans le tab Q&A. Le meilleur moment pour y répondre, ce sera sur les tables tout à l'heure. Donc voilà, merci beaucoup Christophe et Cornel. Et maintenant, je vais laisser la place à Thomas. Merci, à tout à l'heure. À tout à l'heure.
Qui est le code architecte chez Payfit et qui va nous partager son retour d'expérience et répondre à toutes vos questions. Donc, posez des questions. À tout à l'heure. On va dire que oui. Bonjour à tous, je m'appelle Thomas Villaren, je vais partager mon écran rapidement pour... Je vous promets, je n'ai pas autant de slides que Cornel. Je suis bavard, mais je ne suis pas un écrivain. Je vais juste rapidement me présenter. Je suis architecte logiciel et je travaille dans le monde du low-code depuis 2013 maintenant. J'ai travaillé pendant presque 7 ans chez Generative Objects, où j'étais responsable du développement de la plateforme. Generative Objects, c'est une plateforme low-code qui a évolué. J'ai mis un ensemble de mots-clés en haut à gauche de ma slide. C'est toutes les... Les keywords par lesquels on est passé chez Generative Objects. Au début, c'était une application, une Rapid Application Development Platform. On parlait souvent de Model Driven Engineering, qu'on en a parlé rapidement sur l'approche orientée modèle.
Il y a eu une période où on parlait de HP APAS, donc High Productivity Application Platform as a Service. Et maintenant, on parle de Low Code Platform, et bientôt, on parlera de MX, Multi Experience Development Platform. C'est le nouveau terme que le Gartner... à consacrer à certaines de ces plateformes comme Madix, notamment OutSystems, qui ont été citées déjà aujourd'hui. Donc, rapidement, Generative Objects, c'est une plateforme qui permet de créer des applications sur mesure pour tout type d'entreprise, TPE, PME, les grands comptes. À l'époque, on a travaillé, je pense que Generative Objects travaille toujours avec des grandes entreprises comme Thales, Météo France, par exemple, qui n'est pas une entreprise, une institution, pardon, l'administration, avec des associations aussi comme APF France Handicap. Et en 2020, Generative Objects prend le tournant de l'open source et va lancer sa plateforme en open source. Je vous invite à contacter Walter Almeida, le CEO de Generative Objects, pour plus d'informations à ce sujet.
J'ai rejoint Payfit cette année, en janvier. Payfit, pour ceux qui ne connaissent pas, c'est un logiciel SaaS pour la gestion de la paie et des employés. On couvre 4000 clients en Europe, sur les 5 pays européens. On a lancé l'Italie cette année sur la paye. Et en fait, pourquoi je vous parle de Payfit et pourquoi on en parle aujourd'hui, c'est parce que Payfit utilise en interne une plateforme low-code qui s'appelle la plateforme Jetlang et qu'on a créée sur mesure pour le besoin. Précis de coder la paye et notamment la complexité de la paye. Je vais vous en dire quelques-uns. quelques mots et après on pourra passer directement peut-être aux questions sur le low-code en général. Donc la plateforme JetLang, c'est initialement un langage d'expression de la logique de paye. Donc ça a été créé comme un langage il y a quelques années quand Payfit s'est lancé pour permettre aux product builders, donc les personnes qui sont spécialistes sur la gestion de la paye et maintenant même sur d'autres domaines RH,
de coder la logique de paye dans les différents pays, initialement en France. Et puis vous connaissez, je pense, tous la complexité de la paye française, du code du travail et des nombreuses conventions collectives. Donc c'est une couche d'attraction qui vient simplifier pour des personnes moins techniques, pas forcément développeurs, à la base l'expression de cette logique de paye. Et autour de cette logique de paye, donc ce langage, on a construit une plateforme qui permet de notamment créer des interfaces où les utilisateurs de Payfit, donc les administrateurs, les RH dans les entreprises, vont pouvoir saisir les données des employés et des entreprises et définir également des workflows automatisés via notre plateforme. En quelques chiffres, juste pour vous donner des trois métriques, une logique de paye en France, en moyenne, c'est 4 000 variables pour un employé, donc c'est assez complexe. Et en termes de vélocité, grâce à cette plateforme utilisée en interne, on intègre très rapidement les évolutions de la loi travail. On a parlé beaucoup de vélocité.
Je pense que c'est un avantage de ce type de plateforme, que ce soit pour un cas particulier comme la paye ou pour des cas plus généraux. qui est plus classique comme la gestion des données. Pour vous donner un exemple, au début du confinement, le gouvernement a mis en place, a mis à jour plutôt la loi sur l'activité partielle, c'est quelque chose qui existait déjà avant, nous ça représentait 5 bulletins de paye par an avant le confinement, et en quelques semaines, mois, on a dû couvrir plus de 23 000 bulletins de paye sur cette logique. Et grâce à JetLang, on a mis en place en France, en deux semaines, la première itération de cette logique. Donc les entreprises pouvaient directement saisir dans l'outil PayFit l'activité partielle de leurs employés et avoir bien sûr l'impact sur le bulletin de salaire, l'impact au niveau des déclarations, etc. Donc voilà, pour Payfit, je vais arrêter le partage d'écran. Et puis je vais... Excusez-moi, je ne sais pas si Marie a déjà des questions.
Oui. Alors, une question de Waiki Wong. C'est donc un bonjour. Quel est le profil des personnes mettant en place des solutions low-code, low-code? Par exemple, profil non-tech, tech. Et si profil tech, quel est leur feedback sur ces nouvelles solutions? Comment est-ce qu'ils le reçoivent? Alors, pour mettre en place la plateforme elle-même, c'est plutôt tech. Généralement, ça va venir de... Dans mon expérience, en tout cas, encore une fois, je suis peut-être baisé par mon expérience, mais c'est... souvent avec les DSI qu'on travaille, pour mettre en place dans une entreprise cette plateforme. En tout cas, chez Generative Objects, je pense que c'est le cas pour les grosses plateformes. Après, c'est souvent par les métiers que le besoin arrive. C'est des plateformes qui sont à l'usage des métiers. Sur les plateformes no-code, c'est assez simple à prendre en main, mais comme l'a dit Cornel, il y a pas mal de limitations sur les cas d'utilisation. Et puis, il y a pas mal de mauvaises pratiques qui font qu'on va faire ça un peu comme dans l'ex.
On va très vite arriver à des cas un peu problématiques où ça ne va pas forcément tenir la charge s'il y a beaucoup d'utilisateurs. On va avoir des problèmes de modèle de données où tout est mis au même endroit. Donc l'idée aussi, c'est de se faire accompagner sur cette mise en place, soit être formé par la plateforme elle-même, soit par des... Les ESN qui connaissent, il y en a pas mal maintenant qui font ça, ou même les éditeurs, Generative Object, qui nous ont accompagné nos clients sur la mise en place de la plateforme et l'utilisation de la plateforme, parce qu'il y a quand même des principes, on parle de low code ou même de no code parfois, mais il n'y a pas de développement forcément, ou alors du développement pour des cas très précis, notamment des règles complexes, le métier qu'il va falloir implémenter à la main. Mais même pour le casino coin, il faut quand même avoir des bonnes pratiques, sinon très vite on peut faire des bêtises et faire des choses qui ne sont pas pérennes dans le temps. Si c'est pour faire du jeu de table, c'est peut-être moins de problèmes, mais si c'est pour faire des outils qui durent quelques années, il ne faut pas y aller à la légère. Alors, tu nous parles de quelques années.
Donc là, j'ai une question qui est, comment peut-on se prémunir du risque de disparition ou de changement drastique des conditions financières de la plateforme low-code utilisée? C'est une très bonne question. Nous, c'était un peu la question qu'on avait beaucoup à Generative Objects, notamment parce qu'on était une petite startup. Et l'idée, c'est de faire le choix entre une plateforme qui est ouverte, alors pas forcément open source, mais c'est le cas bientôt de GenerativeX, mais qui est ouverte. qui permet aux entreprises de lire le code généré, d'avoir la main sur la base de données, donc avec des bases de données classiques, pas forcément un format propriétaire comme vont le proposer certains éditeurs du domaine. On parlait beaucoup de PowerApps, notamment. PowerApps, effectivement, j'ai cru voir passer une question. Est-ce qu'on est obligé de rester dans le... Dans l'écosystème, c'est un peu la limite de ce type de plateforme quand on est sur un grand éditeur, c'est qu'on en tire le meilleur profit en restant dans ce cocon, dans cet écosystème. Mais si on veut pouvoir changer, dans ce cas-là, peut-être réfléchir à est-ce qu'on n'a pas une plateforme qui est plus flexible, qui va générer du code qui appartient au client, par exemple.
Dans une stack techno assez classique, souvent c'est du Java ou du C Sharp avec du front en JavaScript classiquement, et les bases de données SQL relationnelles ou non relationnelles d'ailleurs, selon les besoins, les usages. Donc ça, c'est des questions plutôt côté tech, côté DSI, côté... Tech leader à se poser et les métiers je pense ne se posera se pose rarement ces questions ils vont plutôt chercher la simplicité d'usage de la plateforme dans la mise en place et pas forcément c'est vraiment un travail à faire entre les deux parties au moment de la sélection de la plateforme d'ailleurs et du coup en parlant de données donc la vie d'apparitions demande Comment réaliser des migrations blue-green ou A-B testing avec du code? Alors, je pense que ça va vraiment dépendre de la plateforme. Il y en a qui offrent ça en... Le versionning en natif et donc qui permettent de gérer des URL, du blue-green, soit du blue-green pour le déploiement, soit de l'AB testing avec la même URL qui va, 50% de vos utilisateurs vont aller sur une version ou l'autre.
Sinon, il faut le faire avec des outils classiques. Quand ce n'est pas faisable, ça peut se faire si la plateforme est bien faite. En fait, encore une fois, tout va dépendre de la plateforme. Si vous êtes dans une plateforme vraiment fermée dans son écosystème, ça va être probablement plus compliqué. Il faudra utiliser les outils mis à disposition de la plateforme. Si vous avez une plateforme un peu plus ouverte, vous allez probablement pouvoir utiliser aussi votre stack, si vous en avez déjà une, qui permet de le faire. Ok. Et du coup, sur un sujet peut-être un peu moins relatif à la plateforme, Francis Guerra nous demande comment peut-on garantir un haut niveau de sécurité dans une appli réalisée en low-code? Est-ce que tu as des conseils à nous donner? Alors oui, la plupart des plateformes viennent avec leurs règles de sécurité, les standards du domaine d'un point de vue technique, l'authentification, la gestion des rôles, les autorisations, les choses comme ça. Là où il y a souvent des problèmes, c'est au niveau de l'humain, c'est-à-dire que comme chez les développeurs, on peut faire des erreurs, il y a des bugs qui arrivent, des failles de sécurité, et là, les développeurs sont parfois plutôt des citizen développeurs, donc des utilisateurs métiers,
et c'est là aussi où l'accompagnement est très important. puisque justement, nous typiquement, la gestion des rôles, on conseillait de faire de la review dessus pour vérifier qu'on couvre bien tous les cas, et définir ensemble quels sont les rôles qui ont droit d'accéder à telle vue, à telle donnée, pour s'assurer qu'il n'y a pas de faille et que la plateforme à tous les niveaux permet de, déjà initialement bien sûr de contrôler l'accès à ces données et éventuellement au vu d'un point de vue interface, et puis ensuite derrière... travailler avec le métier pour bien définir en amont les règles sur ces vues et s'assurer que c'est bien fait dans la plateforme. Parce que c'est souvent un problème humain en termes de configuration, comme dans beaucoup de failles de sécurité. Alors d'ailleurs, je pense que ce sera peut-être la dernière question, on va voir, mais à ce sujet, Nicolas Décosté demande comment se passent et se gèrent les interactions entre les équipes Le Code et les équipes de dev traditionnelles?
Est-ce qu'il y a des histoires à nous raconter là-dessus? Généralement, très très bien. Alors, ça dépend comment ça se présente, bien sûr. Si on arrive, nous, initialement, je vous ai parlé rapidement du fait qu'on se tendait comme une plateforme d'application de développement rapide au début. Et arrivé dans une DSI, les développeurs vous voient comme un générateur de code qui vient prendre leur métier, donc ça ne se passe pas très bien. Mais derrière, quand on vient couvrir des besoins qui sont, par exemple, remplacer la feuille Excel pour des cas qui représentent quand même un bon pourcentage, je dirais 80-90% des projets que j'ai pu faire avec Generative Object, c'était initialement une feuille Excel qui devenait problématique et où la DSI et les développeurs internes n'avaient pas pu répondre aux besoins. L'idée, c'est que là, c'est le métier qui prend la main et du coup, c'est une co-construction entre le métier qui a le besoin fonctionnel, les experts low-code qui, eux, viennent expliquer comment fonctionne la plateforme et former les métiers et les développeurs, et les développeurs qui, eux, vont ajouter justement...
de la partie low du low code, donc la partie à valeur ajoutée, donc s'il y a des règles métiers un peu complexes à implémenter, s'il y a des connexions à des systèmes internes à faire ou à mettre en place des technologies de recherche un peu particulières, je pense. On parlait d'Elasticsearch par exemple tout à l'heure, peut-être qu'il faut se connecter à un Elasticsearch, si la plateforme ne le fait pas en natif, peut-être qu'il va falloir faire une interaction, mettre un connecteur en place avec cette plateforme-là, et c'est là l'intérêt du low-code, c'est que des développeurs vont pouvoir se focaliser sur des tâches à forte valeur ajoutée, et le low-code, le reste de la plateforme va permettre de créer... On va dire la plomberie et toutes les vues automatiquement générées. Ce qui n'empêche pas, juste pour terminer, d'avoir également des développeurs front qui ont offert des widgets très classes par rapport aux widgets qui sont souvent un peu ternes, comme on a pu voir sur les captures d'écran de Cornel. J'ai une autre petite question à laquelle tu peux répondre.
Je pense que c'était de babouzer. Au-delà du fait que les solutions permettent à des personnes moins tech ou non dev de concevoir des applis, est-ce qu'on a des métriques sur le gain de temps de développement? Je vous donnais la métrique de l'activité partielle chez Payfit. En deux semaines, on avait... On avait développé la première version. C'est quand même une interaction très rapide. Je n'ai pas de comparaison possible avec un temps de développement en interne, mais je pense que ça va être... C'était beaucoup plus complexe. Et sur l'expérience que j'ai pu avoir chez NRT Objects, les métriques, c'est par exemple dans un des projets qu'on a fait, on a remplacé une personne, pas remplacé, on a fait gagner un ETP avec un projet. Donc cette personne qui passait sa son année à faire de la saisie dans Excel de données à différents endroits, a pu se focaliser sur des tâches un peu moins... Avec plus de valeur ajoutée en tout cas. D'autres exemples, peut-être plus de coûts, on a fait économiser en termes d'erreurs à certaines entreprises qui utilisaient également Excel pour gérer la supply chain par exemple.
On a pu faire économiser de l'argent parce qu'il y avait souvent des erreurs de copie entre 15 Excel parce qu'il y avait de la consolidation de 30 fichiers Excel différents. L'application low-code permet de s'assurer derrière, avec les règles métiers qui ont été implémentées en low-code, de valider les données, d'éviter des grosses commandes de matériaux bruts, par exemple, qui peuvent aller sur des montants assez importants, ce que j'ai pu voir. Ok, merci beaucoup. Alors là, les dernières questions qui nous restent, elles concernent PowerApps. Donc, à tout le monde, vous pouvez continuer de les poser dans le tab et surtout, on pourra y répondre lors des tables rondes. Éventuellement, s'il y a une dernière question pour Thomas, on peut y répondre. Et sinon, je vais rendre la main à Noémie pour introduire les... Les tables rondes pour la suite. Si vous avez des questions, je serai sur une des tables vides pour échanger avec vous, si vous le souhaitez. Bon, parce que sinon, il y en a une, le temps que Noémie arrive, qui est pour PowerApps, mais qui est applicable à tout.
C'était sur les tests automatisés. Comment faire du test automatisé? Non, mais sinon, vas-y. Tu veux que je réponde à ça? Oui, Cornel, peut-être que ce sera plus pertinent que moi sur cette question. C'est un outil spécialisé de test qui vient dans la plateforme. Mais tu ne fais pas du TDD. Tu fais du test automatique. Car justement, le low code, le nombre d'usages où tu mets des marchés de code est limité. C'est un peu contraire à la philosophie. L'objectif est d'écrire moins de code, pas plus de code. Donc, tu n'as pas aujourd'hui de TDD, mais le code reste très atomique en fonction. Et même sur PowerApps, dans les limites, il n'y a pas de custom functions, ce qui est une limite assez importante et je pense qu'ils vont le rajouter.
Mais voilà, donc des tests automatiques, j'avais vu un environnement si simple. Qui fonctionne out of the box, tu vas juste, ça fonctionne en fait, tu enregistres ou tu fais tes tests. Et je vous conseille de l'utiliser, c'est dans les fonctionnalités expérimentales depuis un moment. Et il y avait encore une autre? Oui, on est bien d'accord que Power Apps n'a de sens que si Office 365 est déployé dans l'entreprise. Non, non, non, non. Donc, il sera dommage d'avoir Office 365 de Play of the Enterprise et ne pas bénéficier de cette offre, car ça vient, je ne sais pas exactement si Office 365 est avec Teams, mais c'est gratuit avec. Et en fait, tu ne payes rien. Et tu peux utiliser le storage Office, le storage SharePoint, ce qui est déjà dans ta société, en fait, quand tu as acheté ça.
Par contre, on a fait une application qui sauvegarde les données que sur Salesforce, car c'était plus simple de faire l'appli avec du low-code PowerApps que de faire avec du low-code Salesforce. Même ça nous aurait coûté une petite fortune. C'est pour cela que le modèle de pricing, c'est très, très important de le comprendre avant d'acheter la suite. Mais vous pouvez utiliser HDR SQL, MySQL, voilà. Après, Alors, vous devrez être aussi attentif sur le fait que quand vous utilisez des choses out of the box, par exemple Office, la qualité des logs et accès aux données et tout est irréprochable. Ça veut dire que vous avez un accès en tant qu'administrateur pour aller en moindre détail de qui a fait quoi. Sans rien implémenter. Alors que si vous faites sur une base de données à part, déjà, il faut implémenter les mesures nécessaires pour provisionning d'accès, pour tout ça. Si vous... Vous êtes dans le cloud, tout s'intègre avec Active Directory, Active Directory, si vous êtes sur Active Directory SQL, mais même, il y a des choses à faire autour.
Donc, il faut être vigilant sur pourquoi vous faites ça. Nous, par exemple, on est en train de s'interdire à faire du MySQL chez nous, car pour faire bien la gestion d'utilisateurs, des accès, log centralisé, quel développeur qui a rentré à un moment donné sur une base de données MySQL, tout ça, il faut le configurer, il faut l'installer, il faut des outils d'entreprise. En fait, quand tu les achètes, c'est vachement cher. Et tu te dis, mais pourquoi? Et donc, pour des fonctionnalités banales. Si vous voulez, on peut continuer dans la table ronde et je vous explique pourquoi on est arrivé à ce choix-là et pourquoi. J'étais contre SharePoint et là, je me trouve avec« wow, comment je ne savais pas qu'il est capable de faire tout ça». Super sophistiqué et simple d'un usage. Et voilà. Donc, j'espère que j'ai répondu.
Oui, c'était super. Et je vais en profiter du coup pour vous remercier tous les deux, Thomas et Cornel, pour vos interventions et les réponses aux questions. Et pour enchaîner sur les tables rondes maintenant, où on va pouvoir retrouver un certain nombre d'experts de Pentalog sur différentes thématiques que vous allez retrouver. dans le chat. Donc, merci beaucoup à tous. Et maintenant, rendez-vous sur les tables pour répondre à des questions plus spécifiques. Merci.
