En trois ans, C2S Bouygues a développé un outil innovant et puissant permettant la digitalisation de la collecte de données pour les utilisateurs en mobilité.
Découvrez aujourd’hui avec l’interview de Patrick LEFEVRE, Architecte Logiciel les enjeux de la création du produit QuickConnect : de sa conception jusqu’à son déploiement chez nos clients.
Bonjour Patrick, peux-tu te présenter ?
Je m’appelle Patrick Lefèvre, j’ai rejoint le groupe Bouygues en 1991 juste après ma formation d’ingénieur en Génie Logiciel à l’Epita.
J’ai commencé mon parcours en tant que développeur, puis chef de projet. Je suis maintenant chef de service et Architecte Logiciel chez C2S Bouygues.
Je travaille sur l’architecture, la conception et la réalisation du produit QuickConnect depuis sa création.
Peux-tu nous expliquer la genèse du produit QUICK Connect ?
L’aventure QuickConnect démarre en 2017 avec la première édition du Easy Digital Challenge, le premier concours d’innovation à l’échelle du Groupe. C’est le projet QuickConnect qui l’a remporté. A l’origine c’était un projet présenté par une équipe de la DSI de Bouygues Immobilier et de COLAS. L’idée d’avoir un outil pour créer des formulaires associés à des équipements identifiés par QR code était née.
Un premier prototype a été développé au Spot Bouygues, le laboratoire d’innovation de Bouygues sur le campus de EPITECH/EPITA. C2S a ensuite été missionné pour développer et industrialiser le projet. J’ai pris en charge le projet compte tenue de mon expérience de dix ans sur le développement de produits similaires.
Quels ont été les principaux défis auxquels tu as dû faire face ?
Ils ont été nombreux et sans vraiment les classer par ordre d’importance je peux t’en citer quelques dizaines :
Le premier défi auquel je pense est que pour répondre à des besoins spécifiques décrits par notre premier client COLAS Bonneville, nous devions construire tout le socle générique du produit QuickConnect. C’est beaucoup plus complexe que de simplement répondre aux besoins spécifiques du client. Complexe implique plus de temps, de réflexion et de charge de travail que ce qu’attend le client. Je ne remercierais jamais assez les personnes de COLAS Bonneville pour leur patience et leur compréhension de cette situation. Mais cela a été gagnant, cette généricité a permis de répondre aux besoins exprimés, et de faciliter la réponse aux futurs besoins non encore exprimés.
Le second défi était le suivant : l’application doit être en mesure d’afficher les formulaires correctement et rapidement. C’est la moindre des choses pour que l’utilisateur adhère à l’application. Chaque élément d’un formulaire QuickConnect, comme un champ Texte, une Liste, un Radio Bouton, se doit de s’afficher rapidement et ceci quel que soit son paramétrage. Et les paramétrages des champs sont nombreux ! Cela nous fait une combinatoire assez conséquente à tester pour s’assurer que l’application reste performante pour chaque formulaire conçu par le client. Et nous ne connaissons pas par avance ces formulaires.
Pour illustrer mon propos et à une toute autre échelle, c’est exactement la même problématique dans un navigateur Web. Un navigateur web est un programme qui affiche des pages internet. Il doit le faire de manière correcte et rapide quel que soit la page Web. Ces pages Web ne sont pas connues par avance par les concepteurs du navigateur Web. Il doit exister je ne sais combien de milliard de pages web dans le monde. Chapeau bas aux concepteurs de navigateur web qui ont relevé ce défi.
Le troisième défi était d’ordre technologique. J’avais l’habitude de concevoir des solutions dans des environnements dit OnPremise, c’est-à-dire dans des systèmes d’information qui utilisent les propres salles machines des clients, avec des équipes d’expert système, réseau et sécurité qui exploitent ces salles machines. Et pour QuickConnect, j’ai choisi le Cloud Azure et poussé le principe de DevSecOps tout au long de la conception. Tous les membres de l’équipe ont dû se former ou augmenter leur expertise sur des technologies, des langages ou outils. Et c’est vrai que QuickConnect est assez riche sur ce point. Nous utilisons différents services Azure comme les WebApi, les WebJob et AzureFunction, les services SQL, les Blob, les Container, les Queue, les EventHub et pour l’automatisation de l’infrastructure, des outils comme TerraForm. Les langages de programmation ne sont pas en reste, nous utilisons DotNetCore et C#, Java, Swift, Angular et TypeScript. Et tout récemment, la liste s’agrandi avec l’ajout de ReactJS, ElasticSearch et SalesForce.
Cette orientation Cloud a dépassé le cadre de QuickConnect, et maintenant nous avons chez C2S des dizaines de collaborateurs certifiés dans les technologies orientées Cloud.
De quoi es-tu le plus fier ?
C’est sans aucun doute la mécanique de scripts que nous avons intégrée dans QuickConnect. C’est un défi technique qui a été pour moi très captivant et passionnant.
La version courte : cette mécanique permet aux concepteurs de formulaires d’intégrer du code dans les formulaires, qui seront exécutés lorsque le formulaire est rempli par l’agent en mobilité. Ces petits bouts de code permettent d’implémenter des règles de validité, des règles fonctionnelles ou des calculs métier en s’appuyant sur les données en cours de saisie.
Cela permet de rendre plus dynamique les formulaires. QuickConnect est une application « No Code », et avec cette mécanique de script, QuickConnect devient un application « No Code ++ », clin d’œil au langage C++ qui m’a tant accompagné.
La version longue : et là, laisse-moi te présenter un peu plus en détail ce qu’il y a sous le capot de cette mécanique de script.
Je voulais avoir :
Après quelques recherches et études, j’ai décidé que nous allions implémenter nous-même notre propre mécanique : Sous le capot, on trouve donc :
Voilà, un peu de défi technique de temps en temps, ça fait du bien aux Geeks que nous sommes.
La version encore plus longue : la grammaire de QCScript est décrite dans la norme EBNF (Extend Backus Naur Form) qui permet, de manière très précise et sans ambiguïté, de définir les différents éléments constituant notre langage. On y retrouve la définition des jeux de caractères, des types de données, qu’est-ce qu’une variable, un opérateur, une fonction dans notre langage et surtout la liste des différents mots clé qui y sont disponible.
La grammaire permet de définir également les actions qui doivent être déclenchées lorsque tel ou tel élément est reconnu. Par exemple, lorsqu’une variable est reconnue dans les sources QCScript, le pseudo code de lecture ou d’écriture sera généré en fonction du contexte
Cette norme EBNF a permis de voir arriver dans notre caisse à outils informatique des outils que l’on appelle des compilateurs de compilateur, comme le très vénéré YACC pour « Yet Another Compiler Compiler ». L’outil que nous avons utilisé est capable de générer un scanner et un parseur depuis la grammaire. Avec notre générateur de code en plus, ces 3 composants forment notre compilateur.
Le rôle du scanner est de parcourir le fichier source contenant du QCSCript, de l’analyser et d’identifier les éléments de notre langage, les tokens.
Le parseur s’appuie sur le scanner et son rôle est de vérifier la cohérence du fichier source et de générer le pseudo code correspondant. C’est le parseur qui vérifie par exemple qu’une constante définie dans le fichier source QCScript ne puisse pas changer de valeur dans le reste du code. Le parseur s’appuie sur notre générateur de code pour générer un fichier QCScriptObj. C’est ce fichier binaire qui contient tout le pseudo code, les tables des constantes, les tables de fonctions. Il est redescendu dans les applications mobiles et servira à notre interpréteur pour exécuter les différentes règles codées en QCScript.
L’interpréteur connais l’ensemble des pseudo codes qu’il peut trouver dans ce fichier binaire. Par exemple, le pseudo code LOAD lui indique de charger une variable, le JMP lui indique de sauter à tel adresse mémoire pour continuer son interprétation, le CALL lui indique d’appeler une méthode en lui passant les paramètres, et ainsi de suite.
Dans cet interpréteur, on trouve des notions de pile, des pointeurs de code, des registres, des tables de symboles, bref des notions que l’on apprend en école d’ingénieur quand on apprend des langages comme l’assembleur. Cela a été hyper captivant d’implémenter cet interpréteur.
Je peux organiser des présentations ou ateliers plus détaillés sur ce sujet de « Compilation dynamique de code » si des lecteurs sont intéressés.
Quels sont les différents composants qui constituent la solution, et sur quelle(s) technologie(s) repose-t-elle ?
Le produit QuickConnect est constituée de 3 parties : la partie Application cliente sous Android et Ios, bientôt sous PC, la partie Administration et la partie serveur back office constituée principalement d’une API et d’un ensemble de composants techniques.
L’Application cliente est destinée aux utilisateurs sur le terrain et leur permet de remplir les formulaires qui leur sont attribués. Les utilisateurs peuvent accéder à l’historique de leurs déclarations, continuer les déclarations qu’ils ont mis en pause ou les dupliquer.
Les utilisateurs peuvent scanner des QRCode et accéder aux caractéristiques et documents des équipements créés sur la plateforme QuickConnect. Le principale composant de l’application mobile reste cependant le moteur de rendu des formulaires.
La technologie utilisée est native aux plateformes, Java pour Android et Swift pour Ios.
L’administration est destinée aux administrateurs, aux concepteurs de formulaires et aux analystes de données. C’est une application Web Angular qui offre à nos utilisateurs les principales fonctions suivantes :
L’Administration des référentiels : Le site permet de créer les organisations du client, afin d’y affecter ses utilisateurs et ses équipements. Toutes ces opérations d’ajout, de modification et de suppression de ces éléments sont également accessibles directement par nos APIs. Ainsi, nos clients peuvent décider si les référentiels sont gérés directement dans QuickConnect ou entièrement dans le SI du client. Dans ce cas, le client utilise nos APIs pour créer une copie en lecture seule de ces référentiels dans QuickConnect.
Internationalisation : permet d’entrer toutes les traductions des libellés associés aux différents formulaires et listes partagées
L’Administration technique regroupe un ensemble d’opérations pour gérer les profils métier, les boites de réception, les WebHook et les connecteurs
Le Serveur BackOffice est le cœur de QuickConnect, même s’il n’est pas visible de nos clients. Il est constitué de plusieurs éléments :
Qu’est-ce qui différencie l’implémentation de QuickConnect des autres solutions de gestion de formulaires ?
L’interconnexion avec le SI de nos clients est toujours une forte préoccupation pour nous. La solution permet à nos clients d’implémenter leur propre connecteur pour venir injecter leurs référentiels dans la plateforme. Nous avons le mode Référentiel Maitre, Esclave ou mixte pour traiter cette interconnexion.
Et à l’inverse, avec notre mécanique de WebHooks, de connecteurs et de compagnons, nous offrons une remontée d’information dans le SI de nos clients depuis la plateforme. Les compagnons nous offrent une certaine agilité pour venir implémenter du spécifique client.
Bien que QuickConnect puisse être utilisé de manière autonome, sans SI client, cette facilité d’interconnexion avec les SI client me parait un élément différenciant.
En deuxième élément, la mécanique des QCScript apporte un vrai plus pour rendre dynamique les formulaires. Elle va bien au-delà des règles de visibilité et formules de calcul que nous avons également et que nous trouvons dans les autres solutions.
Comment se gère la montée en charge du produit ?
La montée en charge est supportée par une architecture SaaS et hébergée sur le Cloud Azure. Nous avons dans cette infrastructure les outils pour augmenter ou diminuer la puissance nécessaire au bon fonctionnement de la plateforme. Cette puissance est liée à deux critères principaux : la capacité de calcul et de stockage.
Le nombre d’utilisateurs connectés à la plateforme et surtout le nombre et contenu de déclarations effectuées permet d’évaluer cette capacité. 1000 utilisateurs réalisant 1 ou 2 déclarations par jour va être moins consommateur que 100 utilisateurs réalisant 10 déclarations avec média.
Les appels à nos Apis par les clients et les appels de WebHook que la plateforme réalise sont aussi mesurés et rentre dans le calcul de la capacité de la plateforme.
QuickConnect a été conçu pour nous permettre de proposer à nos clients deux modes d’hébergement. En fonction de son usage de la plateforme, le client peut bénéficier d’un hébergement mutualisé, à moindre cout, mais dont les performances dépendent de l’usage de plusieurs autres clients. C’est un mode économique, fait pour les clients avec peu d’utilisateurs et acceptant cette contrainte.
Le deuxième mode d’hébergement que nous proposons est un environnement dédié aux utilisateurs du client. Cela représente un cout plus important, mais qui permet d’ajuster les ressources uniquement de son usage. C’est un mode dédié à nos clients ayant un nombre d’utilisateurs important ou avec un fort potentiel de croissance.
Quels sont les enjeux de maintenance du produit ?
Comme pour tout logiciel, la règle d’or est « Il faut que cela marche ! ». Pour ça, la maintenance est pour moi un point essentiel et nécessite de prendre une place importante dans l’organisation de l’équipe. Essentielle car la maintenance a un impact financier direct. La correction d’un bug découvert en phase de développement ou recette est beaucoup plus facile à traiter que si le bug est remonté depuis les plateformes de production.
Une bonne gestion de la maintenance participe à limiter au maximum les temps d’indisponibilité et d’augmenter la productivité de nos utilisateurs. Elle permet d’améliorer la qualité du produit que ce soit en termes de fonctionnement mais aussi de sécurité.
Au-delà de la réaction à la suite d’une remontée de bug, nous sommes dans un cycle d’amélioration continue de nos tests unitaires automatisés et de mise en place de non-régression. Ce processus est extrêmement important pour nous.
C’est un choix d’entreprise qui est fait ici pour intégrer les notions de sécurité et d’environnement. Sécurité car nous devons en permanence répondre aux nouvelles failles et aux nouveaux types d’attaque. Environnement car à C2S, nous avons un axe de réflexion majeur en cours sur les différentes actions possibles à notre niveau pour être le plus Green IT possible.
Comment prends-tu en compte les demandes spécifiques des clients ?
En termes de communication, nous utilisons le logiciel Mantis pour que nos clients puissent déclarer des bugs et des demandes d’évolution. Bien évidemment, l’équipe QuickConnect peut être contactée par mail ou téléphone, et notre équipe commerciale reste à l’écoute de nos clients.
Nous rencontrons régulièrement nos clients via des CoProj et réalisons des démonstrations à nos futurs clients. A ces occasions, nous étudions les demandes spécifiques qui nous sont présentées afin de déterminer quelle est la manière la plus appropriée pour y répondre.
Deux cas peuvent se présenter :
Dès le début de la conception, nous avons prévu d’intégrer dans l’architecture de QuickConnect une mécanique de WebHook et des Compagnons pour répondre aux besoins spécifiques de nos clients. Cela nous permet de venir greffer dans la plateforme des fonctionnalités dédiées à nos clients.
Le fonctionnement de la mécanique WebHook est le suivant :
Le WebHook peut être implémenté et hébergé par C2S pour répondre au besoin spécifique. Le client a aussi la possibilité d’implémenter et d’héberger son propre WebHook pour répondre à ses exigences.
Les Compagnons QuickConnect sont des programmes externes qui ne font pas partie de la plateforme. Ils sont développés par C2S pour répondre à des besoins spécifiques. Par exemple, la base de données dédiée PowerBi pour les clients achetant cette option est alimentée par un compagnon. Son traitement principal est de transformer la structure JSon d’une déclaration en modèle classique de table relationnelle SQL.
Ces compagnons servent en général de pont entre la plateforme QuickConnect et le SI de nos clients.
Peux-tu nous parler des prochaines évolutions du produit ?
Les évolutions prévues pour 2022 sont les suivantes :
Merci Patrick pour cette très belle interview !
Joseph Lorgeoux, Chargé de communication et Marketing
Vous avez trouvé cet article intéressant ? Partagez le sur vos réseaux sociaux !
Siège C2S – WOJO, Issy-les-Moulineaux
41-43 rue Camille Desmoulins, 92130 Issy-les-Moulineaux
Depuis plus de 30 ans nous sommes l’Entreprise de Services du Numérique du groupe Bouygues.
Nous travaillons en étroite coopération avec les DSI et les métiers de la construction, des télécommunications et des médias du Groupe.