Agile

Qu’est ce que le coaching agile ?

Qu’est-ce que le coaching agile ? Qu’est-ce qu’un coach agile ? Qu’est-ce qui le différencie d’un consultant ? Quelles sont ses responsabilités ? Quelles sont les compétences attendues ? Quels sont les différents niveaux d’intervention ? Comment le client peut choisir son coach ? Qu’est-ce que précisément la posture de coach ? En quoi le coaching professionnel contribue à la réussite du coaching agile ?

Au début, les prestations de coaching agile se pratiquaient auprès des équipes de développement logiciel où les coachs agiles étaient des praticiens de l’agilité plus ou moins expérimentés, qui avaient déjà empruntés ce parcours vers l’agilité au niveau de leurs équipes respectives.

Aujourd’hui, le coaching agile est pratiqué de manière très hétérogène par des personnes de compétences et de parcours professionnel différents. Est-ce satisfaisant pour l’activité de coaching agile en entreprise ? Le problème n’est pas là car il s’agit, en réalité, de clarifier ce que signifie faire du « coaching agile » et « être coach agile ».

Confusions, interprétations et incompréhensions suscités par le coaching agile impacte la qualité de la relation entre le coach, son client et les bénéficiaires du coaching, donne une image déformée ou négative de ce que peut apporter une prestation de coaching en entreprise.

Pour cela, cette série d’articles se propose de redonner le sens des fondamentaux du coaching agile, en l’occurrence sur la base de mon expérience professionnelle de plus de dix ans en tant que coach agile et coach professionnel certifié par l’état.

Qu’est-ce que le coaching agile ?

Ce premier article a pour objet de donner une définition simple et précise de ce qu’est une prestation de coaching agile.

Quelles sont les origines du coaching ?

Le terme coach vient du verbe anglais to coach qui signifie « entraîner » dans le domaine sportif ou « faire répéter un rôle » dans le domaine artistique. Il est issu par étymologie du français « coche » qui au XVème siècle était une voiture de transport de voyageurs tirée par des chevaux et conduite par un « cocher ». Leur rôle évoque bien celui du « guide » qui accompagne ses passagers d’un point à un autre en leur faisant franchir les obstacles.

L’activité de coaching nous vient des Etats-Unis, dans les années 50 où l’on voit apparaître de plus en plus de coachs destinés aux stars de cinéma afin de les aider à gérer leur célébrité et qui s’est ensuite étendue au milieu sportif.

C’est dans les années 80 que le coaching est apparu dans les entreprises américaines, puis un peu plus tard dans les entreprises européennes.

La pratique du coaching en entreprise s’est réellement développée dans les années 90 pour répondre à des problématiques spécifiques de certaines personnes, en général des dirigeants d’entreprise pour avoir des résultats concrets sur le court terme en termes de développement professionnel.

Le coaching professionnel s’est beaucoup étendu depuis et ne concerne pas que les managers et les chefs d’entreprise mais aussi tous les salariés présents dans l’entreprise.

Un coach est un acteur de la transformation qui va aider une personne, une équipe ou une organisation à trouver elle-même les réponses dont elle a besoin pour lui permettre d’atteindre le résultat (ou l’objectif) qu’elle s’est fixée.

Cette activité repose sur la croyance que c’est la personne, l’équipe ou l’organisation qui dispose de toutes les ressources nécessaires pour atteindre son résultat attendu.

C’est quoi le coaching agile ?

Le coaching agile est une prestation d’accompagnement dont le domaine d’expertise est l’agilité, pour une durée déterminée d’une personne, d’une équipe ou d’une organisation dans son parcours vers l’agilité pour des résultats concrets, observables et mesurables.

En ce sens, le travail du coach agile va consister à accompagner tout en partie une organisation dans sa transformation agile sur le plan organisationnel, technique et humain.

Quels sont les types d’intervention de coaching agile ?

Les prestations d’accompagnement sont soit orientées coaching d’équipe ou coaching d’organisation, le coaching individuel étant généralement compris dans les prestations précitées.

Pour le cas où le niveau d’intervention demandé est du coaching d’organisation, la prestation de coaching va consister à aider l’organisation à se transformer à tous les niveaux.

Pour cela, le ou les coachs agile procèderont dans un premier temps à une évaluation de la situation, à l’élaboration de la stratégie de transformation et du plan d’accompagnement au changement tant sur la composante organisationnelle, technique et humaine.

Pour le cas où le niveau d’intervention demandé est du coaching d’équipe, la prestation de coaching va consister à accompagner les équipes à la mise en place d’un système agile de production de solutions métiers.

Pour cela, la prestation de coaching s’orientera vers la formation et un accompagnement des équipes à la mise en place d’un système agile de production afin d’améliorer l’innovation, la réactivité et la qualité des produits réalisés.

Dans les deux cas, le coach agile est en soutien du client pour les changements à opérer dans le cadre de la transformation agile.

Le coach agile va aider son client à atteindre en toute autonomie ses objectifs, tout en le faisant bénéficier de son expérience pour notamment lever les obstacles connus et anticipables des transformations agiles.

Le coach agile est alors en soutien des équipes et de l’organisation pour les rendre plus performantes dans leur production par le développement de leur autonomie, auto-organisation, collaboration, responsabilisation et engagement.

C’est une bonne situation ça testeur ?

Sans doute qu’ Edouard Baer répondrait ce qui suit comme dans Asterix : Mission Cléopâtre à la question :  C’est une bonne situation ça scribe ?

« Vous savez, moi je ne crois pas qu’il y ait de bonne ou de mauvaise situation. Moi, si je devais résumer ma vie aujourd’hui avec vous, je dirais que c’est d’abord des rencontres. Des gens qui m’ont tendu la main, peut-être à un moment où je ne pouvais pas, où j’étais seul chez moi. Et c’est assez curieux de se dire que les hasards, les rencontres forgent une destinée… Parce que quand on a le goût de la chose, quand on a le goût de la chose bien faite, le beau geste, parfois on ne trouve pas l’interlocuteur en face je dirais, le miroir qui vous aide à avancer. Alors ça n’est pas mon cas, comme je disais là, puisque moi au contraire, j’ai pu : et je dis merci à la vie, je lui dis merci, je chante la vie, je danse la vie… »
Pour ma part, je serai moins lyrique et je ne dirai que « Oui »Beaucoup de testeurs ont découvert ce métier par hasard. En effet, il est très peu enseigné, voire peu valorisé dans les écoles d’informatique ou de management de systèmes d’informations, même si depuis quelques années de nombreuses formations diverses fleurissent sur le marché pour permettre d’appréhender toutes les facettes de ce Métier.

Cependant, ceux qui ont « le goût de la chose bien faite » savent que ce métier exigeant s’apprend, qu’il requiert des qualités spécifiques et qu’il permet de réelles évolutions de carrière.

Un peu d’histoire…

Dans les années 90, pour les plus expérimentés d’entre nous, nous entendions : « LE TEST  ? mais on en fait tous ! c’est pas un métier ! »  Conséquence : la qualité des SI laissait à désirer.

Partant de ce constat et dans le but de remédier à cette problématique, une méthode de tests a été créé au sein du Groupe Aubay. Une nouvelle Méthode et un nouveau Métier étaient nés : l’Homologation des S.I.  Cela a permis, par la suite, de réaliser des projets au forfait : Les Tierces Recettes Applicatives.

Fort de ces nouvelles bonnes pratiques, Aubay a décidé de mettre en place une formation sur 2 mois et de recruter de nouveaux types de profils. Puis, d’autres acteurs du marché ont également investi ce secteur.

Afin de garder ce savoir-faire acquis de longue date et le faire évoluer, Aubay a pris la décision de convertir cette filière très spécifique en pôle d’expertise, reconnu auprès de nos clients et favorisant l’intégration de professionnels du test.

Des profils divers

Les collaborateurs du pôle test et automatisation viennent d’horizons divers. Se retrouvent des développeurs, des chargés de clientèles / Métiers « banque et assurance » ou encore des professionnels titulaire d’un bac +5 d’un tout autre domaine et qui ont de l’appétence pour les systèmes d’informations.  Les chefs de projet aimant le pilotage et la gestion d’équipe pourront également s’épanouir car les enjeux et la stratégie peuvent évoluer en cours de projet.

En tout état de cause, la rigueur, le sens de l’organisation et de la communication, la capacité à se mettre à la place du client et la capacité à prendre du recul sont exigés par nos clients

Pour parodier Sully, nous pouvons ajouter que « Rigueur et persévérance sont les 2 mamelles de la validation » **.

Des formations spécifiques

Les compétences d’un testeur sont de 3 ordres :

  • Compétences fonctionnelles/métiers
  • Compétences tests
  • Compétences techniques/outils

Chacune de ces compétences est développée selon le chemin de carrière choisi.

Pour les testeurs fonctionnels

Il nous parait important d’accompagner nos collaborateurs sur les aspects métiers par des formations dédiées et/ou par des formations e-learning.

Concernant le métier du testeur, la Certification ISTQB Foundation est souvent demandée par nos clients. Elle correspond au code du permis de conduire : ce n’est pas parce qu’on ne l’a pas qu’on ne sait pas conduire. Ce n’est pas parce qu’on l’a qu’on sait conduire mais c’est quand même mieux de l’avoir ! Une grande partie de nos testeurs a bénéficié d’une POE (Préparation opérationnelle à l’emploi) d’une durée de 3 mois au cours de laquelle ils mettent en application leur savoir-faire et leur savoir-être sur des projets concrets (Stratégie, conception, exécution, bilan, Agile…). l’Ecole de la Qualité Logicielle est l’un de nos partenaires privilégiés.

Les compétences techniques indispensables pour un testeur portent sur les requêtes SQL et les tests de Webservices ainsi que sur la maitrise d’un ou plusieurs outils de management de test.

Pour les testeurs automaticiens

Un bon testeur automaticien est d’abord un bon testeur fonctionnel-manuel. Il doit en effet comprendre ce qu’il automatise afin de gagner en efficacité.

Mais il doit avoir également une compétence technique de programmation plus ou moins importante suivant les outils et suivant son niveau d’intervention (mise en place d’architecture d’automatisation ou évolution/maintenance)

Il doit également acquérir de la méthode et la maitrise d’outils. Là encore, les POE voire des contrats pro sont des formations indispensables. Dans ces formations, sont abordés des outils d’automatisation tels que Selenium, UFT, SoapUI.

Un métier offrant des possibilités d’évolution

Le métier de testeur offre différents chemins de carrière. Après avoir expérimenté les fondamentaux du test, le collaborateur peut évoluer

  • Vers de l’organisation et le management
  • Vers de l’expertise métier
  • Vers de l’expertise test

La carrière du collaborateur se construit d’abord par le collaborateur lui-même qui identifie ses qualités et compétences et la carrière qu’il souhaite réaliser. Ensuite, de concert avec son manager, des formations sont identifiées et suivies. Les formations certificatives de type ISTQB sont privilégiées. Enfin, des missions correspondant à la voie choisie sont engagées et le collaborateur est accompagné, si nécessaire, lors du début de ses nouvelles fonctions.

La motivation, la formation et l’accompagnement sont quelques-uns des facteurs clés de réussite de l’évolution de carrière d’un professionnel du test.

Un métier évolutif

Le métier de testeur est un métier qui évolue en même que temps que l’informatique. Les tests mobiles ont émergé lors de l’essor spectaculaire des téléphones portables.

L’avènement des méthodes Agile a considérablement fait évoluer le rôle du testeur. Pour caricaturer, il est passé du rôle « de l’inspecteur des travaux finis » à un acteur présent dès la définition des besoins, permettant une meilleure compréhension du besoin et évitant alors la création d’anomalies.

La mise en œuvre du Devops bouscule également l’organisation traditionnelle des tests.

L’évolution du métier favorise l’émergence de nouveaux outils et de nouvelles méthode de test.

[ne pas hésiter à consulter le syllabus associé à la très récente formation Testeur Technique Agile]

Conclusion

Testeur est donc une bonne situation ! Si vous avez le goût de la chose bien faite, n’hésitez pas à nous rencontrer !

Contact : recrutement.qualification@aubay.com

**« LABOURAGE ET PÂTURAGE SONT LES DEUX MAMELLES DE LA FRANCE » MAXIMILIEN DE SULLY, 1638

L’apport de la programmation neuro-linguistique à la facilitation agile

Mon rôle de facilitatrice agile

Depuis 3 ans, mon rôle de facilitatrice consiste à accompagner les équipes d’un projet afin qu’ils atteignent leurs objectifs dans un contexte de transformation agile, plus précisément dans le cadre SCRUM.

De mon point de vue, ce rôle nécessite :

  • d’être bon communicant pour transmettre les bonnes pratiques et se faire comprendre des équipes ;
  • de l’humilité ;
  • une grande capacité d’adaptation, afin de faciliter au quotidien le travail de l’équipe dans ce cadre méthodologique.

J’ai découvert la PNL (programmation neuro-linguistique) alors que je cherchais à approfondir mes connaissances sur les outils de communication et d’accompagnement au changement individuel et collectif qui pouvaient m’être utile en tant que facilitatrice.

Qu’est-ce que la PNL ?

John Grinder et Richard Blander s’intéressent, dans les années 70, à la modélisation des modèles comportementaux et posent ainsi les fondations de la Programmation neuro linguistique connue et enseignée de nos jours.

Ce modèle se propose de décrire comment fonctionne un système humain (une entreprise, une famille, une personne) en s’intéressant à son langage.

C’est en effet, à travers le langage, que nous véhiculons notre modèle du monde aux autres.

Le contenu et la structure de ce langage sont des programmes que nous avons appris et automatisés à travers nos expériences, notre culture et nos sens.

Ils sont ainsi révélateurs de notre pensée.

Par la description du langage, la PNL se propose de mieux comprendre notre système de pensée, et nous donne des clés pour le modifier dans certaines situations quand celui-ci nous limite.

Les outils de la PNL

La PNL est un modèle proposant plusieurs niveaux de certification (du niveau technicien au niveau coach) et une multitude d’outils permettant d’accompagner individuellement mais de mon point de vue également collectivement.

En tant que certifiée PNL niveau technicien, j’ai eu l’opportunité de découvrir ces outils :

  • Le recadrage
  • La modification des submodalités
  • Les positions de perception
  • Le Milton Modèle
  • Le Méta Modèle
  • L’ancrage
  • L’association/la dissociation
  • La détermination d’objectifs
  • Le générateur de comportement nouveau

Mon rôle de facilitatrice agile avec la PNL

J’ai utilisé, pour ma part, un outil qui peut se révéler très utile au démarrage d’une équipe agile : les niveaux logiques.

Les niveaux logiques est, à l’origine, un outil qui permet de classer par niveau les informations que notre cerveau recueille et sont révélatrices de notre processus de pensée.

Les 6 niveaux logiques s’organisent ainsi :

  • l’environnement (la base)
  • le comportement (ce que nous faisons, notre activité)
  • les capacités (nos compétences)
  • les croyances et les valeurs (nos motivations, pourquoi nous agissons)
  • l’identité (Qui nous sommes ?)
  • les niveaux d’appartenance (notre idéal, notre vision)

Pour commencer, chaque membre de l’équipe donne sa description personnelle de ce qu’il est ou fait à chaque niveau.

Cela permet à chacun de mieux se connaitre et de mieux connaitre l’autre, la vision de son rôle, son travail, ses collègues au sein de l’équipe.

Dans un deuxième temps, il s’agit de partir de cette base personnelle pour voir comment travailler mieux ensemble en tant qu’équipe, non pas en dissolvant les différences, mais en les connaissant pour afin de mieux les vivre.

Les points communs sont aussi relevés pour trouver les valeurs et la vision de l’équipe dans l’atteinte de ses objectifs.

Il est possible d’aller plus loin en travaillant sur les représentations d’un membre de l’équipe à chacun des niveaux quand celles-ci sont limitantes.

Il s’agira ici de l’accompagner individuellement afin de comprendre cette représentation et de l’aider à la dépasser.

Dans un deuxième cas, lors de divergences d’opinion ou de conflits, le rôle de facilitateur peut être d’aider l’équipe à échanger plus sereinement, en favorisant un espace de communication.

Pour cela la PNL, propose « le processus du facilitateur ».

Tout d’abord, il s’agit de poser le cadre, en confirmant auprès des deux parties l’objet du désaccord, puis de demander et d’obtenir leur accord pour les accompagner vers la résolution du conflit.

L’échange peut ainsi commencer.

Il sera nécessaire que chacun puisse présenter à l’autre :

  • une intention positive expliquant sa position
  • ses objectifs et ce qui est important pour lui
  • son but et ce que son opinion/position lui apportera d’encore plus important (en termes de vision, de valeurs)

Jusqu’à arriver à un cadre commun, où les deux parties trouvent finalement un point d’accord sur une valeur, un idéal commun à atteindre.

Pour aller plus loin..

D’autres approches proposent également des outils de communication et d’accompagnement au changement tels que l’approche systémique de PALO ALTO, qui s’intéresse aux difficultés que peut rencontrer un individu dans ses interactions avec autrui et l’amener à trouver des solutions pour les résoudre.

Nous sommes évidemment à la frontière de l’accompagnement thérapeutique et, de mon point de vue, le facilitateur n’a pas vocation à devenir le thérapeute d’une équipe en entreprise.

Cependant ces approches ouvrent le champ de la créativité dans de nombreuses situations grâce à des outils qui se révèlent utiles et efficaces dans l’accompagnement des personnes et des équipes agiles en entreprise.

Ouvrages sur la PNL pour en savoir plus

Derrière la magie – La programmation neuro-linguistique – Editions – Intereditions

Comprendre et pratiquer la PNL dans votre vie professionnelle et personnelle – Editions Intereditions

 

Le développement d’applications mobiles multiplateformes

Dans un contexte où le marché mondial des applications mobiles devrait dépasser les 120 milliards de revenus en 2020, il est important, pour rester concurrentiel, de développer des applications mobiles plus rapidement en offrant des délais de commercialisation plus courts.

Les applications natives

Au début du développement d’applications mobiles, il n’y avait pas d’autre choix que de faire un développement en utilisant les technologies fournies par les constructeurs pour les différents OS (IOS, Android). Les langages de programmation pour du développement natif sont très différents d’une plateforme à l’autre (Objectif C ou Swift pour IOS et Java ou Kotlin pour Android). Il est donc compliqué pour un développeur de maitriser l’ensemble de ces technologies et généralement, un développeur se spécialise uniquement sur un seul OS. Par conséquent, le développement d’une application multi OS sur un environnement natif implique des coûts élevés et nécessite souvent une équipe de développeurs par OS.

Les applications multiplateformes

Au fil des années, le marché du mobile a vu émerger des cadres de développement qui permettent d’écrire un seul code applicatif et de l’exécuter sur les différentes plateformes. Ainsi plus besoin de connaitre tous les langages de programmation associés à chaque plateforme. Les coûts et les délais pour la création d’une application utilisant cette technologie se trouvent ainsi largement réduits.

Il existe actuellement 2 approches différentes pour ces nouveaux frameworks de développement multiplateformes :

  • Le développement d’applications ‘hybrides’ qui utilisent des technologies web (HTML, CSS et Javascript) pour créer l’application et son contenu. Cette solution est composée de 80% de technologies web et de 20 % d’extensions permettant l’accès aux fonctionnalités natives du système d’exploitation. Le tout est encapsuler dans une enveloppe native pour que l’application hybride puisse être utilisée comme une application native. C’est une solution fréquemment retenue pour “porter” rapidement un développement web sous forme d’application disponible sur les stores.

Ionic, Cordova et Phonegap sont des exemples de technologies hybrides.

  • Le développement d’applications ‘natives générées’ qui compilent un même code source en différentes applications natives. Il ne s’agit plus d’une vue web exécutée dans un container comme dans le développement de type hybride, mais bien d’un code natif construit pour chaque plateforme. Avec ce type de framework, l’interface utilisateur est obtenue à l’aide de contrôles natifs (contrairement au développement de type hybride) ce qui apporte des performances d’affichage similaire au natif.

React Native, Xamarin, Flutter ou encore Kotlin/native sont des exemples de technologies de type natif généré.

Ses avantages

L’avantage principal d’utiliser ces frameworks multiplateformes est bien sûr leur développement unique compatible pour tous les OS évitant ainsi des développements spécifiques pour chaque système d’exploitation. L’application sera développée plus rapidement et à moindre coût, et son déploiement en sera simplifié par une sortie sur toutes les plateformes en même temps. Implicitement, la maintenance et l’évolution des applications créées seront également plus simples et plus rapides à mettre en œuvre.

Un autre avantage à ne pas négliger est la montée en compétences. En effet, en utilisant ce type de technologie multiplateforme, le développeur n’utilise qu’un seul langage pour la création d’une application qui sera disponible sur toutes les plateformes du marché. De plus, un développeur ayant déjà des connaissances de développement avec des technologies web pourra très rapidement produire des applications mobiles sans trop d’effort en s’orientant vers des frameworks de type hybride qui utilise des technologies similaires.

De plus, l’utilisation de ces types de frameworks est parfaitement adaptée pour mettre en place des projets de type MVP (Minimum Viable Product) ou de prototypage.

L’ergonomie et les interfaces

Il existe une réelle différence entre ces deux types de frameworks lors de la conception des interfaces utilisateurs. En utilisant le cadre de type hybride, l’interface utilisateur sera identique sur toutes les plateformes, ce qui peut être un problème pour certain client mais vous pourrez obtenir une bonne expérience utilisateur et des bons modèles de navigation d’un point de vue visuel.  Avec les frameworks de type natif généré, vous allez pouvoir avoir un rendu équivalent au mode natif car ce cadre de développement utilise l’ergonomie et les composants standards des différents OS.

Les performances

Bien évidemment, les applications natives font un meilleur usage des ressources et peuvent exploiter au maximum les fonctionnalités des téléphones. Les applications développées en multiplateformes sont souvent moins performantes pour le développement d’applications complexes à forte utilisation de CPU ou GPU comme les jeux. Pour tout autre type d’applications (gestion et/ou restitution), les performances sont très acceptables.

De par son architecture et son mode de compilation, les frameworks de type natif généré obtiennent de meilleure performance par rapport au cadre hybride.

Conclusion

Les frameworks de développement d’applications mobiles multiplateformes ont longtemps été décriés compte tenu de leurs performances réduites. Au fil des années, cet écart s’est considérablement réduit jusqu’à devenir quasi identique pour certains frameworks de type natif généré comme Xamarin ou Flutter. Malgré tout, les applications natives restent supérieures en termes d’expérience utilisateur mais beaucoup plus coûteuses.

Il parait donc évident que le choix du cadre de développement d’une application mobile dépendra du type d’application que vous souhaitez développer et de son budget associé. Si votre application exige des traitements complexes avec des fonctions graphiques très évoluées, il vaut mieux vous orienter vers du développement natif car vous risquez de rencontrer des soucis de performance. En revanche, pour le développement d’application de type distribution de contenus (qui concerne environ 80% des applications mobiles) vous pourrez avoir des résultats très satisfaisants en utilisant les frameworks multiplateformes avec l’avantage d’avoir des délais de développement et de mise sur le marché extrêmement réduits.

N’oubliez pas lors de vos choix, que les cadres de développement hybride et natif généré ne sont pas identiques et la seule caractéristique commune entre ces deux framework est un code unique pour différents OS. Il est donc important pour vous, de choisir une technologie qui réponde à vos besoins, exigences ainsi qu’à votre public cible pour créer une application gagnante.

Chez Aubay, au sein de la Digital Factory, nous avons privilégié la solution Ionic pour des développements de projets mobile multiplateformes.

Vous avez des questions, une idée de projet de développement mobile ?
N’hésitez pas à nous contacter !

Didier GIOT
Responsable de la Digital Factory

Automatiser la vérification des paraphes et signatures d’un contrat

De nombreux contrats sont rédigés et signés au quotidien, que ce soit par une ESN comme Aubay ou par les diverses entreprises que sont nos clients, notamment les banques et assurances. Afin qu’un contrat soit juridiquement valide, il est nécessaire pour chaque mandataire d’apposer un paraphe sur chaque page du contrat ainsi que sa signature sur au moins une page du contrat.

Aujourd’hui, ces contrats sont vérifiés manuellement lors de la signature, et un paraphe peut vite être oublié sur un long document. Cette erreur anodine peut invalider un contrat et causer de nombreux problèmes pour l’entreprise l’ayant rédigé.

C’est pourquoi nous avons travaillé sur un projet permettant la détection des paraphes et signatures sur chaque page du contrat, ainsi que la vérification de la validité de ce contrat. Cet outil repose sur des méthodes de traitement d’images et d’intelligence artificielle. La détection des clauses manuscrites est en cours d’implémentation, elle permettra d’obtenir un outil encore plus performant.

Récupération et traitement des données

La récupération d’un contrat peut se faire sous plusieurs formats (pdf, image) et la qualité du contrat n’est pas toujours optimale. En effet, le document n’est pas toujours scanné droit et des éléments parasites peuvent apparaître lors du scan. La première étape du traitement consiste donc à convertir les contrats en images que l’on va redresser puis à supprimer au mieux les éléments parasites.

 

Exemple de nettoyage d’un contrat, les éléments parasites en haut de l’image sont supprimés et le contrat est redressé.

Pour cela nous utilisons la bibliothèque openCV en python, le redressement se fait par rapport aux lignes horizontales (texte et parfois lignes de tableaux) et le nettoyage est obtenu à l’aide d’opérations morphologiques (érosion, dilatation).

Une fois le contrat nettoyé, sa vérification s’effectue en deux étapes. Dans un premier temps, il faut localiser l’ensemble des paraphes et signatures du contrat puis il faut vérifier que ces éléments sont valides.

Localiser les paraphes et signatures

Pour pouvoir vérifier la validité des paraphes et signatures sur le contrat, il faut d’abord pouvoir trouver ces objets sur l’image. Le terme objet est utilisé car pour localiser les paraphes et signatures le projet utilise un réseau de neurones dit de « détection d’objet ». Ce type de réseau sert à localiser toutes les apparitions d’éléments qu’il s’est entraîné à reconnaître sur une image. C’est le même type de réseau qui est utilisé pour les voitures autonomes : le réseau détecte alors les voitures et les piétons depuis l’image de la caméra de la voiture. Dans notre cas, nous détectons les paraphes et les signatures depuis l’image du contrat.

Schéma expliquant le fonctionnement global du réseau

Pour qu’un tel réseau fonctionne, il faut l’entraîner avec une base de données conséquente et correspondant à la réalité de ce que l’on souhaite détecter. Il nous a été fourni plusieurs contrats pour entraîner le réseau, mais leurs nombres étaient insuffisants. À l’aide d’un procédé nommé DataAugmentation et des contrats que nous possédions nous avons alors pu créer des milliers de nouveaux contrats, avec paraphe et signature. C’est avec ce lot de contrat que nous avons entraîné le réseau. Cependant, ce procédé tend à diminuer l’efficacité du réseau. Nos résultats sont bons, notre réseau est capable de détecter les paraphes et les signatures, mais il aurait été encore meilleur avec une plus grande diversité de contrats.

Figure 1: Le score 0.84 est la certitude du modèle en sa prédiction, 1 est une prédiction certaine

Nous avons choisi un modèle pré-entraîné pour la détection d’objet nommé RetinaNet pour créer notre réseau. Choisir un modèle pré-entraîné permet d’avoir les premières couches du modèle fixées. Celles-ci ne servent pas à détecter l’objet, mais uniquement à extraire des features d’une image. Le travail de Transfer Learning a ensuite été effectué pour pouvoir détecter les paraphes et signatures.

Le modèle est entraîné sous le Framework Detectron2. Créé par le FAIR ( Facebook AI Research), ce Framework est l’un des plus évolué permettant des temps d’entraînement raccourci et des résultats probants.

Vérification de la validité du contrat

Deux méthodes sont possibles pour vérifier la validité des paraphes et signatures trouvées :

  • La première suppose que le nombre de mandataires est connu et permet un traitement rapide.
  • La seconde n’émet aucune hypothèse, mais est plus coûteuse en temps

Les deux méthodes sont implémentées dans le projet.

Dans la première méthode, le nombre de mandataires est connu, s’il est par exemple de deux, il est possible de vérifier de manière algorithmique la présence de deux paraphes par page. De même pour les signatures où il faudra vérifier que les deux signatures sont présentes pour les pages concernées.

En revanche, la seconde méthode est plus complexe. Il faut s’assurer que le même nombre de paraphes est présent à chaque page et que ceux-ci correspondent.

Les différents paraphes de chaque page sont alors comparés afin de rassembler chaque groupement de paraphes. On appelle ces groupements une classe. Chaque classe correspond à un mandataire.

Afin de savoir si des paraphes appartiennent à la même classe (paraphes effectués par la même personne), nous calculons 6 différentes features pour chaque image. Les features sont des vecteurs contenant des informations sur l’image.

Chaque feature est obtenue par un processus algorithmique sur l’image que nous avons mis en place. Tous les vecteurs sont concaténés un en seul. Ainsi, chaque image possède un vecteur contenant les informations issues des 6 features. Pour comparer deux paraphes, nous comparons les distances (norme euclidienne) entre les vecteurs features des images correspondantes.

Les features calculées pour chaque paraphe sont : le profil radial, l’histogramme, le zonage, le profil, les points clé et la direction.

Dans un contrat de cinq pages à deux mandataires, les paraphes sont regroupés en 2 classes de 5 éléments chacune (Ici le contrat est invalide, il manque des paraphes aux pages 2 et 5).

Pour les pages où des signatures sont détectées, nous vérifions qu’il y a autant de signatures que de classes dans le contrat.

NB : Puisque nous ne possédons en général pas un exemple de la signature d’un mandataire, il n’est pas possible dans ce projet de vérifier que la signature est valide. Il est toutefois possible de vérifier la validité d’une signature en la comparant à une originale à l’aide d’un modèle siamois.

Performances

La performance de l’outil en terme de temps dépend de la méthode utilisée ainsi que du matériel.

Le graphique suivant donne le temps de traitement d’un contrat en fonction de son nombre de pages et du matériel utilisé. On remarque qu’une utilisation sans carte graphique est peu envisageable, cependant un GPU peu puissant permet de gagner un temps considérable. L’utilisation d’une carte RTX4000 permet la vérification d’un contrat de 22 pages en moins de 5 secondes.

La performance en terme de qualité pour le modèle de détection s’effectue à l’aide d’une métrique nommée mAP (mean average precision). Cette métrique permet d’obtenir un score entre 0 et 1 où 1 est un modèle parfait.

Notre modèle obtient un mAP de 98.6% (0.986) ce qui est un bon résultat, car il est proche de 100%. Cependant afin d’obtenir des résultats plus réalistes nous aurions besoin de tester le modèle sur une plus grande base de données (issue de contrats réels).

Evolutions futures

Ce projet est à l’état de POC et il est possible d’envisager plusieurs améliorations pour une mise en production.

La première serait de faire le lien avec l’équipe RPA d’Aubay afin d’automatiser la collecte des contrats et de renvoyer un mail aux mandataires en cas d’oubli sur l’un des contrats.

Une seconde amélioration serait la vérification des clauses manuscrites (« lu et approuvé », « bon pour accord » …). Cette étape est déjà amorcée : nous avons ré-entraîné Retinanet pour localiser les mentions « Lu et approuvé ». Il faudrait, pour détecter tout type de mentions, une base de données suffisamment fournies en exemple de mentions manuscrites.

Conclusion

Le projet permet donc de vérifier la validité de paraphes et des signatures sur un contrat. Plusieurs méthodes permettent d’arriver au résultat en fonction des hypothèses émises sur les contrats. Il serait encore possible de rendre ce projet plus performant notamment en utilisant un plus grand nombre de contrats pour l’entraînement.

Figure 2: interface de présentation du projet permettant une utilisation facile et rapide

Banque de détail – Digitalisation du Parcours client

Dans un monde en perpétuelle évolution, les attentes des clients « professionnels » sont de plus en plus élevées et les banques de détail doivent optimiser leurs plateformes et processus afin de pouvoir y répondre favorablement.
C’est pour cela que les banques sont en permanence appelées à revoir leur parcours client (Customer Journey) tant en terme d’optimisation qu’en terme de rapidité d’exécution.Retards de paiement, activité saisonnière, rachat de clientèle, acquisition immobilière, véhicule utilitaire …etc, les besoins des clients « professionnels » sont multiples et nécessitent une très grande réactivité de la part des banques afin de répondre aux exigences de délais de satisfaction.
Par conséquent, dans un contexte de plus en plus concurrentiel, le financement de ces besoins devrait être particulièrement souple, adapté et rapide, dans le but de permettre aux professionnels d’honorer leurs engagements vis à vis de la clientèle, de garder intacte leur capacité concurrentielle, et d’espérer gagner des nouvelles parts de marché.Afin d’atteindre cet objectif, deux axes essentiels devraient être analysés, dans l’ordre :

  • D’abord, L’optimisation du processus de crédit, depuis la phase « demande », en passant par les phases : « étude », « décision » et « octroi » jusqu’à la phase « recouvrement ».
  • Ensuite La digitalisation du processus.

Et concrètement
I/ L’optimisation du parcours client :
Dans un contexte concurrentiel accru en matière d’offres de crédits, les banques de détail sont soumises à une pression réelle en matière de coûts, de gestion des demandes, et de délais de réponse à leurs clients. L’accélération du traitement d’un dossier devient alors un impératif.L’analyse de la démarche d’optimisation tourne autour des points suivants :

  1. L’analyse de l’existant:
  • Cartographier le processus Crédit
  • Analyser lesdits processus :
  • identifier l’ensemble des processus impliqués dans le parcours client ;
  • identifier les étapes sans valeur ajoutée ;
  • identifier les irritants aussi bien côté Client final que Client intermédiaire (conseiller).
  1. Les constats :
  • Clients moyennement satisfaits ;
  • Collaborateurs irrités à cause de la multitude des outils utilisés pour le montage des dossiers.
  1. La recherche des causes:
  • Manque de simplicité et de fluidité du processus ;
  • Délais de traitement et entre les étapes trop longs ;
  • Faible réactivité des organes de décision;
  • Peu de visibilité sur l’avancement de la demande ;
  • Faible anticipation des besoins clients.
  1. La solution :
  • Eliminer les étapes sans valeur ajoutée ;
  • Paralléliser les étapes indépendantes ;
  • Concevoir la carte des processus cibles ;
  • Mettre, progressivement, en place les processus cibles en fonction de leur criticité.
  1. Le Suivi et Mise à jour:
  • Le contrôle et le suivi du processus mis en place se fera à travers les résultats fournis par les indicateurs de performance ;
  • Des propositions d’amélioration issues de l’exploitation quotidienne devront se faire périodiquement dans un contexte d’amélioration continue ;
  • La formation des nouveaux conseillers.

II/ la digitalisation : Une démarche pas à pas
Pour être efficace, et avoir un retour d’investissement rapide, la digitalisation, à l’instar de l’optimisation des processus, devra se faire par étapes.Trois étapes essentielles sont à prévoir :

Etape 1 : Analyse de la situation digitale actuelle
Cette étape devra identifier :

  • Les étapes du process actuel concernées par la digitalisation ;
  • Les interactions entre l’outil principal du montage de crédit et les systèmes adjacents (Gestion des garanties, des assurances, le déblocage des fonds;
  • Les convergences et les divergences par rapport à la concurrence en matière de digitalisation du process crédit (Benchmark)

Etape 2 : Identification et priorisation des besoins en digitalisation cible
La digitalisation ne devra pas se faire en bloc. Elle doit se faire pas à pas en ciblant les étapes à forte valeur ajoutée.La priorisation des besoins en digitalisation doit répondre au critère de retour sur investissement.Aujourd’hui les phases « Demande de crédit » et « Décision de crédit » gagneraient à être digitalisés en priorité : le but étant de raccourcir le temps de traitement grâce à :

  • Un cadrage et affinage de la demande client dès le départ
  • Une possibilité de faire diverses simulations instantanées, ayant pour but de guider le client dans le choix de son montage financier
  • Le calcul automatique du pouvoir décisionnel et l’affectation du dossier au bon organe décisionnaire

Etape 3 : Conduite de changement relatif à la transformation digitale
Outre le volet technique, la digitalisation englobe également un aspect humain qu’l faudrait intégrer dès le lancement et tout au long du projet par :

  • L’implication des conseillers ainsi que les différents intervenants dans le process et la définition des besoins de digitalisation ;
  • La formation des collaborateurs aux nouveaux process ;
  • La sollicitation des conseillers terrain pour remonter des propositions d’amélioration

Et en parallèle :

  • Faire adhérer les intervenants dans le processus d’octroi : « Front-Office » et « Back-Office »
  • Former les conseillers aux nouveaux processus et aux nouvelles applications
  • Préparer l’environnement technique pour le déploiement et la généralisation de la solution cible

 

De technical Leader à Scrum Master

Tout d’abord, je tiens à me présenter : je m’appelle Laurent et j’ai une expérience de 18 ans en développement informatique. Je travaille chez Aubay depuis maintenant 4 ans.

Aujourd’hui, je souhaite partager avec vous mon expérience et mon parcours professionnel atypique. En effet, j’ai exercé tour à tour les fonctions de développeur, de chef de projet technique, tech lead et enfin scrum master.

Pourquoi cette évolution ?  

J’ai souhaité évoluer de tech lead à scrum master tout d’abord par goût pour les dispositifs organisationnels et la performance d’une équipe de développement. Cette évolution a également été animée par la magie des rencontres, en particulier de professionnels inspirants, qui sont capables de nous faire aimer telle ou telle pratique.

Quel a été mon parcours ?

J’ai découvert le métier de scrum master lors d’une mission chez un des grands acteurs du secteur automobile ? J’ai participé à un projet en mode agile qui fut couronné de succès et qui a été décisif pour ma carrière. Cette réussite a principalement été due à la forte compétence et la vision du coach agile en place sur ce projet. Le coach agile, collaborateur Aubay, nous a transmis les valeurs et la philosophie du métier. Ce fut une révélation pour moi.

Ma passion et mon investissement personnel (lectures diverses, réflexions sur les problématiques agiles, …) n’ont fait que confirmer mon aspiration professionnelle. J’ai validé tous mes acquis en assistant à des formations et en passant des certifications de PSM1 (Scrum Master) et de Safe Agilist.

Des qualités et compétences propres au Scrum Master se retrouvent dans la fonction de Tech lead.

Les fonctions de scrum master et de tech lead ont plus de points communs que nous le pensons. Une des premières similarités touche au domaine de la communication. En effet, les deux métiers ont un rôle de facilitateur en termes de communication, tant avec les développeurs qu’avec les équipes qui gravitent autour du projet. Ils ont pour objectifs communs de mener leurs équipes vers l’excellence, de les accompagner au quotidien, et de soulever les points qui suscitent les bons questionnements.

Pour aller plus loin, je peux donner des exemples concrets de ressemblance :

  • S’exprimer en public lors des rituels,
  • Faciliter la communication entre les parties prenantes internes ou externes,
  • Être une interface dans le respect du cadre Scrum. Par exemple, lors d’une réflexion sur la conception de nouvelles fonctionnalités, mon rôle a été d’initier la discussion technique et design, de faire émerger les problématiques par le questionnement adéquat en nouant des liens forts entre product owner et l’équipe de développement. Ceci demande un dosage fin dans la relation à l’équipe et au métier afin de mettre en place des interactions efficaces.

Les écueils à éviter

Pour illustrer mes propos, je prends l’exemple d’un de mes premiers projets en tant que scrum master dans une grande banque. Mon rôle était d’assurer le suivi de deux applications bancaires d’envergure.

L’objectif ici est de bien comprendre quels sont les écueils à éviter lorsque l’on débute dans une nouvelle fonction malgré la maîtrise de la technique :

  • Oublier l’aspect technique afin ne de pas interférer avec les développeurs.
  • Oublier sa posture d’écoute.
  • Ne pas avoir des réponses toutes faites mais s’insérer dans le dispositif même complexe et agir de façon empirique petit à petit en absence de réponses toutes faites.

Il faut être extrêmement vigilant car toute équipe est différente et se gère donc différemment. J’aime bien reprendre la triade « Tester, inspecter, s’adapter » comme base de travail pour que l’équipe progresse.

Il est néanmoins important de préciser que la posture d’écoute et de réaction surpasse à cet instant la connaissance technique.

Comment faire pour progresser ?

Tout au long de votre évolution professionnelle vous pourrez trouver du soutien au travers de formations et certifications (Scrum, Safe agilist). Elles sont très importantes car elles valident les fondamentaux et elles mettent la théorie en regard de la réalité du terrain.

Ces formations permettent de considérer ce qui est acceptable du point de vue du cadre Scrum, de ce qui ne peut pas l’être et de ne pas évoluer dans la sphère de la psycho-rigidité mais de faire progresser l’équipe dans la pratique agile. Ces bonnes pratiques sont aussi confrontées au sein de la practice agile Aubay. En effet, nous mettons en place des workshops, nous favorisons la transmission de compétences et multiplions les communications éclairantes sur des domaines transverses : facilitation graphique, activités de coaching innovantes, problématique forte du travail à distance en mode agile.

La réussite à la clef

En ce qui me concerne, le résultat fut concluant. L’équipe fut en évolution constante et sa maturité agile s’est affirmée malgré les contingences et les difficultés de production. La transition de technical Leader est une exhorte en action à la réflexion organisationnelle, demande une amélioration continue du Scrum Master sur ce qui se fait, tout comme le technical leader envisage les nouvelles versions d’Angular.

CICD via Gitlab

Je vous propose une série de trois articles concernant la CICD via Gitlab.

  • Pipeline-trigger, un outil pour les gouverner tous.
  • Remote gitlab-ci, moins y’en a mieux c’est.
  • Docker factory, l’usine à images !

Pourquoi ces trois articles ? Je pars d’un constat simple. Maintenir un CICD dans une entreprise qui évolue est très chronophage. Etre en phase avec les normes de sécurité, être assez modulaire pour prévoir les spécificités de chaque projet ou encore gérer les tokens et autres variables globales… peut vite devenir un cauchemar. Et je sais de quoi je parle.

Consultant DevOps pour une société dans le secteur de l’assurance, notre environnement de CICD est composé d’une trentaine de projets différents. Tout autant de gitlab-ci.yml à maintenir. Je vais donc vous exposer les solutions mises en place après les webinars et autres conférences docker/gitlab auxquels j’ai participé.

PIPELINE-TRIGGER

En tant que DevOps mon équipe a été amenée à mettre en place des outils permettant de faire des livraisons unitaires, service par service, et globales, tous les services d’un coup. Jusque-là, normal me direz-vous … Et pourtant la première difficulté était là. Comme je vous le disais dans l’intro, la société dans laquelle j’effectue ma mission possède une trentaine de projets dont certains sont dépendants les uns des autres.

Pour automatiser au maximum, nous avons créé un projet supplémentaire pour rajouter une couche d’abstraction au fait de devoir lancer des jobs sur chacun de projets.

Dans ce nouveau projet, des jobs vont venir faire un trigger sur les autres projets via des curl pour être en mesure lancer des pipelines à distance.

Imaginons un cas simple, vous avez deux projets A et B à déployer et chacun est indépendant l’un de l’autre. Dans ce cas précis, on crée un job pour chacun des deux projets qui va faire le déploiement, un gitlab-ci qui pourrait ressembler à ça :

 

Maintenant, imaginez que A ait besoin que B soit déployé (ou buildé, ou pushé sur Nexus… bref, X raisons d’avoir une dépendance). La ça devient compliqué.

Pourquoi ?

Parce que pour lancer le job `deploy_A` on a besoin que le job `deploy_B` soit FINI ! Le problème étant que curl ne permet pas ça, car curl renvoie un status_code=OK si le curl lui-même s’est bien passé, s’il a réussi à créer un pipeline distant, c’est tout, sans aucune considération de l’état du pipeline distant que ça a créé. Et là pas le choix que de faire des actions manuelles qui consistent à lancer le pipeline de B, attendre la fin puis lancer le pipeline de A. Dans cet exemple où il n’y a que 2 projets, l’impact est limité. Quoique cela peut vite devenir contraignant si les pipelines durent dans le temps (migrations de données ou autres…), mais dans le cadre d’une trentaine de projets, avec des dépendances croisées un peu partout ou du legacy, c’est l’enfer.

Heureusement on est vite tombé sur un outil open source qui nous a sauvé la mise et a grandement augmenté notre capacité de management de notre CICD.

Pipeline-trigger

Cet outil est un simple script python, vraiment très bien pensé qui a été créé pour répondre à la problématique précédemment expliquée. Je profite de ce billet pour remercier l’auteur du script qui a eu cette idée géniale.

Je ne vous expliquerai pas le code ici, je vous invite donc à le lire, en suivant le lien plus haut, pour une meilleure compréhension du fonctionnement de l’outil.

Voyons ce qui change avec cet outil pour nos deux jobs précédents :

On a changé l’image pour utiliser l’image officielle qui contient le script.

Mais le changement se fait surtout au niveau du curl, là où maintenant on a un nouveau mot clé, `trigger`.

  • Comme le script utilise l’api de gitlab il est nécessaire de lui fournir un `API_TOKEN` afin de s’authentifier.
  • Le user a besoin d’un `DEPLOY_TOKEN` propre à chaque projet, il faut aller dans les settings des projets pour pouvoir les créer.
  • Le `PROJECT_ID` propre à chaque projet
  • `–target-ref` la branch que l’on souhaite utiliser sur le projet distant pour créer le pipeline
  • `–env` permet d’envoyer une variable d’environnement au pipeline distant.

Quelle est l’utilité d’utiliser le pipeline-trigger, puisque de prime abord il a l’air de faire EXACTEMENT la même chose que curl?

La grosse différence est dans le fait que `trigger` ne se contente pas de créer un pipeline distant à l’instar de curl, il attend la réponse du pipeline, et fait échouer le job si jamais le pipeline distant échoue !

Grâce à cet outil on est capable d’automatiser complètement l’exemple vu précédemment. Pipeline-trigger permet aussi d’exécuter des jobs manuels de façon automatique, c’est toujours bon à savoir, alors n’hésitez pas à lire la doc pour en apprendre plus.

REMOTE GITLAB-CI

Maintenant que vous êtes en capacité de pouvoir tout contrôler à partir d’un point central, on va voir comment optimiser la maintenance et la modularisation de notre CICD.

Plus on a de projets et plus on a de gitlab-ci. Et à chaque modification il faut penser à répercuter la modification sur tous les gitlab-ci… Ça peut vite devenir dur à maintenir et encore plus à faire évoluer.

Donc l’article sera consacré à une fonctionnalité bien trop méconnue de gitlab, les includes.

Une fois de plus mon équipe s’est confrontée à la gestion de nos gitlab-ci. Avec notre trentaine de projets, à chaque modification sur un job il fallait faire une trentaine de MR aux techleads des projets pour que ce soit mergé, puis remonté jusqu’en master… bref, un enfer.

Alors on a fouillé la doc de gitlab en étant persuadé que les ingénieurs qui bossent chez gitlab avaient pensé à une solution. Et effectivement. On a trouvé les includes qui permettent d’importer un gitlab-ci d’un projet distant… de la vraie magie !

On a donc fait un projet d’abstraction exactement comme pour le pipeline-trigger, pour n’avoir qu’un seul endroit avec tous les gitlab-ci.

Du coup plutôt que d’avoir un gitlab de plusieurs centaines de lignes dans chaque projet, on les a tous remplacé par ça :

6 lignes !!! De cette façon la gestion était transparente pour les développeurs et on avait plus besoin de faire de MR vers leurs projets pour faire nos modifications, cela a permis de mettre une distanciation entre la partie purement développeur et purement DevOps.

Le fait est que nous avions toujours notre problème de duplication de code pour chaque projet.

Du coup on s’est dit qu’on allait appliquer le même principe à ce même projet contenant tous les gitlab-ci. On a donc éclaté tous les jobs de nos gitlab-ci et avons créé un gitlab-ci par job.

Oui, ça fait quelques fichiers… mais vous allez voir, le bénéfice en vaut largement la chandelle.

Rien que de faire ça a permis de supprimer l’intégralité du code dupliqué. Car pour chaque job identique, on a laissé le même gitlab-ci sans en créé un qui serait la copie parfaite du premier. Et donc au final ça ne faisait pas tant de fichiers que ça en plus.

Une fois tous ces nouveaux gitlab-ci on a modifié les gitlab-ci que nous avons exporté. Pour rappel dans notre projet on avait à la base ça :

Nous avons maintenant ça :

Sauf que nos gitlab-ci service-X.gitlab-ci.yml eux ont toujours leurs centaines de lignes.

Donc appliquons les includes… et maintenant ils ressemblent à ça :

Infiniment plus simple.

Une fois fini de mutualiser nos gitlab-ci on s’est rendu compte en fait que nous étions passé d’une trentaine de gitlab-ci à une demi-douzaine avec une vingtaine de jobs différents. Notre CICD était finalement moins complexe que nous ne le pensions. Et vous, comment est votre CICD ?

DOCKER FACTORY

Et voici le troisième article de la saga CICD.

Après avoir vu le management des pipelines, le management des gitlab-ci… nous avons cherché, une fois de plus, à vouloir mutualiser les autres ressources disséminées dans notre gitlab.

Le plus gros point que nous ayons relevé à ce moment-là, était les variables CICD, tous les tokens et autres variables nécessaires au fonctionnement du pipeline. Et ça sur notre trentaine de projets… c’était la galère dès qu’un token n’était plus valide, il fallait trouver lequel ne fonctionnait plus et tous les endroits où le changer.

Notre objectif était donc de supprimer toutes ces variables et de pouvoir les contrôler à un seul endroit à l’instar des triggers et des gitlab-ci.

Pour la troisième fois nous avons créé un projet pour faire une couche d’abstraction.

Dans ces projets on a ajouté toutes les variables de tous les projets et on s’est dit, et bien comme on utilise des images docker dans notre CICD on va ajouter ces variables à nos images. On va donc faire nos propres images avec une surcouche sur les officielles que nous stockerons chez AWS.

Voilà comment on a fait :

  • Création d’un docker-compose (pourquoi compose et pas docker tout simple ? juste pour pouvoir utiliser le fichier .env)

  • Création d’un docker-compase.overrides

  • Création du .env

  • Mise en place du gitlab-ci

Ce qui donne cette architecture:

Et voilà avec ça vous avez votre propre usine à images avec toutes vos variables à l’intérieur.

Je tiens à préciser que ce moyen n’a vocation à être utilisé que pour des images utiles à la CICD, jamais pour des images destinées à aller en PROD, ce serait une énorme faille de sécurité.
Pensez aussi à mettre vos variable en protected/masked dans votre projet afin de tout de même faire les choses proprement.

Puisque qu’on aborde la sécurité, mon prochain article sera certainement sur Anchor un outil très utile pour la détection de failles de sécurité des images à destination de la PROD !

 

Datastax / Cassandra

Datastax/Cassandra : Bonnes pratiques de modélisation et cas d’usages dans le e-business

Datastax Server Entreprise (DSE) est une base de données distribuée dite « no-SQL » (pas seulement SQL) s’appuyant sur la base open source Cassandra qui fait partie à l’origine des projets de la fondation Apache. Datastax est le principal contributeur de ce projet Apache Cassandra à hauteur de 80% (source Github).

Dans cet article nous allons expliquer pas à pas les caractéristiques d’une telle base de données et comment celle-ci est utilisé par les entreprises.

Base de données distribuée

Le terme de base de données distribuée fait référence au traitement de la donnée sur plusieurs « nœuds » dans un cluster de machines, la donnée volumineuse est découpée en « partition » entre les différents nœuds de la base, allégeant ainsi l’allocation de ressources pour le traitement des données (écriture / lecture).

Chaque nœud est unique et contient une partition des données. Cela permet une grande disponibilité des données mais surtout une haute tolérance aux pannes. A chaque instant un nœud est élu coordinateur pour gérer les requêtes clientes. (Voir fig. 1)

Figure 1 -Cluster Cassandra en « peer to peer »

Afin d’avoir une communication entre chaque nœud, l’architecture de Cassandra s’appuie sur un protocole de communication dit “peer to peer”. Le protocole va permettre la propagation de l’information sur tous les nœuds d’un même Data Center.

Cette architecture permet :

  • L’écriture et la lecture des données avec des temps de latence réduits,
  • Une augmentation de la charge de traitement des données entre les différents nœuds,
  • Une réduction drastique du risque de panne (si l’un des nœuds tombe un autre prend le relais),
  • La gestion d’un flux important de données par l’ajout de nouveaux nœuds.

Le cluster doit assurer au maximum le théorème dit de CAP (Voir Fig.2) :

  • Cohérence des données. (Consistency)
  • Disponibilité (Availability)
  • Résistance au partionnement. (Partition Tolerance)

Cassandra à fait le choix de se positionner sur la disponibilité et la résistance au partitionnement. En clair, celle-ci va prioriser la disponibilité des données sur leur cohérence via son architecture distribuée en nœuds. Néanmoins des solutions existent pour satisfaire ces trois points critiques. Tout d’abord Cassandra sauvegarde les données sur des partitions réparties sur des nœuds distincts du cluster. Le mécanisme dit de réplication respecte la règle du quorum de nœuds qui doit toujours être un nombre impair de copies : le nombre minimum de réplications est de 3 et constitue une valeur par défaut.

Mais ce mécanisme de réplication ne garantit pas que les données soient cohérentes entre chaque nœud du cluster. Si les données critiques (par exemple : coordonnées bancaire d’un client), il convient d’obtenir une cohérence irréprochable.

Pour ce faire les requêtes des clients sur la base peuvent fixer un niveau de consistance. Ce niveau de consistance indique combien de partitions vont être interrogées afin de vérifier que la donnée est bien mise à jour dans plusieurs partitions réparties sur des nœuds distincts du cluster. Ce système est utilisé en lecture et écriture pour les requêtes en base.

Figure 2 – théorème CAP

Relationnel ou non-relationnel ?

Cassandra utilise un format de base de données dit non relationnel entre les tables par opposition aux bases de données relationnelles (Oracle, MySQL, SQL Server…) qui mettent en œuvres des relations « 1 à n » ou « n à n » entre les données des différentes tables (formes normales).

L’architecture NoSQL de la base de données Cassandra est basée sur la technologie « BigTable paper » inventée par Google. Le choix d’une orientation en colonne des données (par tuples de valeurs) permet de compresser les données et d’accélérer le traitement des opérations (MIN, MAX, SUM…) et la recherche sur des valeurs de clés communes.

Figure 3 – représentation du modèle de données

Le modèle de données des tables Cassandra se décompose ainsi :

  • La colonne : plus petite unité de la base, elle est composée d’un nom, d’une valeur et d’un timestamp (indication de la dernière mise à jour).
  • La Ligne : se compose d’une clé d’identification et d’une multitude de colonnes.
  • La famille de colonnes : Regroupement de ligne.
  • Le Keyspace : regroupe un ensemble de famille de colonne.

Figure 4 – BDD orientée colonne

Cette vitesse de traitement est indispensable dans le contexte lié au Big Data, de gros volume de données peuvent être envoyés de façon continue en base il s’agit d’être efficient en lecture et en écriture.

De plus les colonnes ne supportent pas les doublons de données (les valeurs nulles ne sont pas stockées), cela permet d’avoir des données compactes et fiables.

Pour effectuer des requêtes sur ses tables Cassandra utilise son propre langage : le CQL ou « Cassandra Query Language ».

Le langage Cassandra Query Language (CQL)

Le CQL est un langage proche du SQL standard, cependant quelques différences existent. Faisons un tour d’ensemble sur ces spécificités.

Tout d’abord la base peut s’organiser de façon à accueillir les données structurées classiques, mais aussi les données semi-structurés (format JSON et XML).

Il est obligatoire de saisir une clé primaire sur une des valeurs pour permettre au cluster de retrouver les données qui sont dispersées sur le data center. La clé est générée par Cassandra utilisant « Murmur3 », une fonction de traitement.

On peut se représenter une table comme ceci :

La clé primaire est appelée « Partition Key », elle est unique et fait référence à une seule partition sur un seul nœud du cluster. Ainsi, Cassandra n’aura aucun mal à récupérer les données relatives à un élément de données.

Cassandra prend également en charge les « Clustering Key » qui contrôlent la façon dont les enregistrements de données sont regroupés et organisés au sein de chaque partition. Les enregistrements dans Cassandra sont stockés sous forme de listes de paires clé-valeur où le nom de la colonne est la clé.

Les bonnes pratiques

Prenons un exemple afin d’illustrer les grands principes de modélisation des données dans Cassandra. Nous créons une table nommée “magasin”, celle-ci va contenir le numéro du magasin, sa localisation, son directeur, une description du magasin et ainsi que ses stocks.

Le numéro d’identification du magasin va nous permettre de retrouver sa trace sur notre cluster en vérifier ce numéro avec ceux présents sur les nœuds.

Data modeling

Les trois principes fondamentaux de conception d’un bon modèle de données sont les suivants.

  1. Répartir les données de manière équilibrée dans le cluster

En choisissant la bonne « Partition Key », les données devront être réparties de façon équilibrée sur l’ensemble des nœuds du cluster afin que chaque nœud puisse récupérer une part égale des données. La distribution de ces données se fait via la « partition key » qui est une clé de partition générée par la base. Le hachage des données se fait pour chaque partition et va décider dans quel nœud la donnée va être stockée.

Figure 5 – Partitionnement et hachage

2) Minimiser le nombre de partitions à lire pour chaque requête type

Les partitions sont un ensemble de lignes qui partagent une même « Partition Key ». Il nous faut créer un modèle qui réduit au maximum le nombre d’appel en lecture en instantané dans un nombre minimum de partitions localisées sur des nœuds distincts du cluster.

Si ce principe n’est pas respecté, cela impacte la performance globale du cluster. En effet, lorsqu’une requête de lecture est lancée le nœud coordinateur va vérifier les nœuds qui contiennent la partition demandée.

Figure 7 – vérification des partitions key

3) Anticiper la croissance du volume de données

Un partitionnement de données qui est pertinent pour une centaine d’utilisateurs simultanés peut devenir un point de rupture unique du point de vue de la performance pour des millions d’utilisateurs simultanés.

C’est pourquoi la « Partition Key » d’une table doit prendre en compte les critères de performance cibles attendus par les applications clientes en appliquant des principes de partitionnement équilibrés sur des volumes croissants de données.

Pas de jointures

L’une des particularités avec le langage CQL est que vous ne pouvez pas effectuer de jointure classique entre deux tables comme on serait tenté de le faire sur un modèle de base classique (jointure clé primaire / clé étrangère).

Pourquoi ?

Vous perdrez énormément en performance et en montée en charge.

Que dois-je Faire ?

Le mot clé est la dénormalisation. Cassandra permet de regrouper dans un seul Keyspace un très grand nombre de données en grandes tables. Chaque table doit ainsi satisfaire à l’exécution d’une requête client. Il faudra donc prendre en compte dans la phase de modélisation des données les futures requêtes clientes afin de regrouper au maximum les données dans des tables uniques.

Créer des requêtes de simulation de charge

Dès la phase de développement, il est nécessaire d’exécuter des requêtes de simulation de charge avant la mise en production

Pourquoi ?

L’objectif est d’évaluer les ressources (mémoire, CPU, stockage) de chaque nœud et le temps d’exécution moyen nécessaires à l’exécution des requêtes. Une charge trop importante peut considérablement accroître le temps de récupération des données d’une requête.

Que dois-je Faire ?

Effectuer des tests techniques dans un environnement de pré-production dont les nœuds du cluster correspondent au dimensionnement des nœuds dans l’environnement de production. Ces tests permettent d’établir des ajustements du cluster tels que :

  • La capacité en nombre de nœuds pour la production
  • L’augmentation / réduction des ressources des nœuds (mémoire, CPU, stockage).
Cassandra dans les entreprises

La base de données Cassandra est utilisée par de nombreuses entreprises possédant des profils variés. Deux cas d’usages dans deux domaines différents (tertiaire et banque) sont présentés.

Accor

Accor est l’un des leaders mondiaux du domaine hôtelier, le groupe dispose de 4900 hôtels répartis à travers 110 pays. Le groupe a dû revoir l’architecture de son réseau en 2015.

L’objectif était de transformer l’ancien modèle de gestion qui ne pouvait plus gérer la montée en charge des demandes de réservations et ne disposait pas de données en temps réelles (les données étaient pré-calculées). Cela amenait à une mauvaise expérience utilisateur et bien souvent à une perte ou une corruption des données.

La nouvelle architecture basée sur un cluster Cassandra répond parfaitement aux critères de montée en charge et permet au groupe Accor de disposer de données de réservations des clients en temps réel.

Figure 8 – Gestion des informations de réservation en temps réel au sein du groupe Accor

ACI Worldwide

ACI Worldwide propose un service de paiement électronique en temps réel et souhaitait une solution de détection de fraude.

Une transaction bancaire peu importe son profil est susceptible de fraude, une couche de détection a donc été mis en place quand une demande de déplacement de finance est créée. Avec l’essor du E-Commerce le nombre de transaction a augmenté de façon exponentielle. En pratique on estime que 1 transaction sur 85 est une fraude.

Les exigences de ACI Worldwide étaient les suivantes :

  • Nécessité d’un stockage de volumes massifs de données de transaction clientes d’une haute complexité.
  • Pouvoir gérer les différents profils de client (marchand / intermédiaire bancaire) et les pics d’utilisation du service.
  • Le but de la plateforme de détection est principalement de passer inaperçu pour le client en ne diminuant pas la vitesse de traitement de la transaction.

La base de données Cassandra est ici utilisée en adéquation avec la plateforme interne de détection de fraude, cette plateforme peut traiter les transactions avec une haute vélocité tout en garantissant la sécurité des requêtes.

En parallèle les données clientes sont utilisées pour améliorer le modèle d’apprentissage de détection de fraudes de la plateforme sans aucune interruption de service ou d’augmentation du trafic.

La solution obtenue combine ainsi prise de décision et Big Data afin d’améliorer le taux de détection des fraudes et de faux positif.

Conclusion

Les principaux avantages de l’architecture Cassandra sont les suivants :

  • Evolution dynamique : L’architecture distribuée d’un cluster Cassandra permet d’augmenter le nombre de nœuds ainsi que la puissance de traitement sans interruption de service.
  • Haute disponibilité : si l’un des nœuds tombe en panne un autre prend le relais.
  • Performances élevées : la scalabilité horizontale de la solution est gérée par l’augmentation du nombre de nœuds.
  • Stockage flexible : Cassandra autorise de nombreux format de données (structuré, semi-structuré). Elle peut s’adapter de façon dynamique en fonction des modifications de la structure des données.

Si vous souhaitez en savoir plus, le site de DataStax contient une documentation fournie et un blog ou la communauté est active. De plus, des workshops encadrés par Datastax sont organisés régulièrement pour se familiariser avec leurs technologies.

Vous pouvez retrouver et vous inscrire à ces événements à l’adresse suivante :

https://www.datastax.com/events/

Source pour la rédaction de cet article

https://www.datastax.com/resources

https://www.datastax.com/resources

http://cassandra.apache.org/doc/latest/cql/

https://mbaron.developpez.com/tutoriels/nosql/cassandra/installation-outils-administration/

https://www.datastax.com/blog/2016/02/most-important-thing-know-cassandra-data-modeling-primary-key

https://netflixtechblog.com/tagged/cassandra

https://www.datastax.com/blog/2019/05/how-apache-cassandratm-balances-consistency-availability-and-performance

Low code/Less Code : Mythe ou Réalité

Depuis quelques temps nous sommes sollicités par la rédaction d’articles ou la réalisation de quelques expériences client sur la mise en pratique du Low code/Less code.

Cette approche du développement informatique, qui a déjà eu des tentatives de mise en œuvre par le passé peut-elle se révéler un moyen de profiter des nouvelles infrastructures cloud à disposition du monde IT tout en incluant les travaux issus du génie logiciel pour nous permettre de délivrer des applications cohérentes et bien construite avec une courbe d’effort beaucoup plus faible.

Alors ce Low Code/ Less Code encore un mythe ou une réalité ?

Le principe de ces solutions est de réaliser des applications informatiques sans code ou avec très peu.

L’idée n’est pas nouvelle, on ne compte plus les applications bureautiques souvent réalisées en shadow IT, mais aussi les générateurs de code, les templates de construction d’application, les ateliers de génie logiciel ou les applications hautement paramétrables sur une filière métier.

L’objectif de toutes ces solutions est de s’éloigner des contingences techniques chronophages pour se concentrer sur les fonctions de l’application.

Si, en plus, l’application peut être conçue réalisée et déployée par des équipes sans ou avec peu de bagages techniques, l’objectif pourrait être atteint.

L’outil historique typique d’une telle approche est le tableur Excel.

Les outils RAD (Rapid Application Development) peuvent être considérés comme les précurseurs dans l’approche Low Code/Less Code.

Les solutions d’aujourd’hui sont toutes basées sur le principe d’un méta modèle qui décrit la problématique du domaine. Elles sont complétées par des outils orientés processus ou interaction afin de manipuler ces données. La conception de l’application se réalise de manière très visuelle à travers un Studio de développement et de nombreux Wizards.

Par contre dans l’état actuel du marché, on peut distinguer deux grandes catégories d’outils en fonction de la population ciblée pour son utilisation : les informaticiens et le non informaticiens. Les deux types d’outils peuvent être inclus dans la même solution.

Un outil de Low Code/Less Code a pour vocation de masquer à ses utilisateurs la complexité technique des solutions mises en œuvre.

La distinction entre les approches Low Code et Less Code (voir No Code) n’est pas toujours très claire.

Par sa structure, l’approche Low Code/Less Code est donc un compromis entre la facilité d’utilisation et les possibilités d’adaptation aux besoins à résoudre.

Toute cette réflexion nous ramène à la problématique essentielle des DSI : faire en interne ou acheter un outil externe. Dans ce cas il s’agit de faire avec les limites et contraintes de ce qui est facile à mettre en œuvre avec l’outil.

Le choix d’un tel outil est donc fortement lié à son contexte d’utilisation.

Si l’on cherche à faire un panorama des solutions existantes, on peut distinguer plusieurs types d’acteurs :

  • Les spécialistes du Cloud qui profitent de leur plateforme pour apporter un composant LowCode/LessCode
  • Les pure players qui sont spécialisés depuis quelques années sur le segment
  • Les Startups qui offrent des solutions alternatives avec des propositions plus ciblées

Quasi systématiquement, ce sont des solutions Cloud parfois regroupées sous le terme de aPaaS (Application Platform As a Service)

De manière générale l’Open Source est peu présent sur ce segment de marché.

Les promesses du Low Code/Less Code sont concentrées sur :

La Facilité :

  • Des applications unifiées qui sont construites sur un mode de conception identique avec un rendu qui se veut uniforme.
  • Des applications nativement responsives
  • Des outils visuels pour la construction des applications
  • Une montée en compétence réduite
  • Un partage mieux compris entre les différents acteurs IT et non IT

La Vélocité :

  • La capacité à délivrer plus rapidement des applications et une meilleure réponse au time to market
  • Un travail collaboratif natif
  • Des évolutions plus fréquentes
  • Des déploiements plus facile avec des chaines DevOps intégrées
  • Des équipes concentrées sur les objectifs métiers

La Robustesse :

  • Des architectures pré définies et éprouvées par la multiplication des applications qu’elles supportent
  • Une infrastructure à la demande
  • Des Services transverse mutualisés tels que la sécurité qui peuvent s’adapter aux contraintes avec un minimum d’impact sur les applications.
  • Des montées en charge facilitées sur les applications

La typologie des applications éligibles à cette approche doit être déterminée en fonction de critères propres à chacune des entreprises. Cependant, l’introduction du Low Code/Less Code a aussi des impacts sur l’organisation de l’entreprise :

  • Rester encore plus en phase avec les demandes métier
  • Trouver le bon équilibre entre Plus d’innovation et Moins de maintenance sur les systèmes Legacy
  • Ne pas laisser ce type d’application dans le périmètre du shadow IT
  • Trouver un bon équilibre dans la répartition des ressources sur ce type d’application
  • Intégrer le processus de choix de ce type de solution dans la culture digitale de l’entreprise
  • Faire adhérer les développeurs à ce type de plateforme

Le choix de ce type d’approche nécessite quelques point d’attention pour permettre de franchir le pas, en particulier :

  • Offrir suffisamment de souplesse pour répondre aux uses cases métiers
  • Permettre une courbe d’apprentissage rapide au regard des outils et différentes aides mise à disposition
  • Etre transparent sur les solutions techniques mises en œuvres pour couvrir l’ensemble des fonctionnalités mise en œuvre
  • Disposer de systèmes d’échanges pour communiquer avec le SI Interne ou dans un cloud hybride
  • Disposer d’un pricing adapté pour une adoption progressive de la solution
  • Permettre la réversibilité des données et des applications
  • Assurer un travail collaboratif associé à un pipeline de déploiement efficace
  • Garantir une sécurité compréhensible et auditable

Les perspectives d’adoption sur ce nouveau marché semblent en plein essor. D’après le GARTNER :

  • En 2016, ce marché représentait 2,5 Milliards de $.
  • Il est estimé qu’en 2020 ce marché atteindra 15 Milliards de $.

Source Gartner

Gartner estime qu’en 2024, plus de 65% des applications seront développées à partir de solutions Low Code, ainsi que ¾ des grandes entreprises utiliseront au moins 4 outils Low code.

En conclusion, les solutions Low Code/Less Code peuvent permettre de réaliser des applications qui ne justifient pas un développement classique sous réserve de vérifier l’éligibilité à ce type de solutions. C’est un moyen temporaire ou définitif qui participe aux interactions entre les différents composants du SI, en remplaçant les traitements manuels pour permettre d’automatiser des processus métiers nécessitant un mode collaboratif sur du traitement de données. Les limites de l’exercice sont liées aux niveaux d’exigences attendus par l’application.