Sensibiliser ses collaborateurs à la cybersécurité

Former ses équipes à avoir les bons réflexes avant, pendant et après une attaque peut vous permettre de sauver vos données, votre système d’information, et aussi de l’argent. 

Accrues depuis le début de la pandémie, les cyberattaques ne cessent de faire des victimes et ce auprès des entreprises de toutes tailles. Il ne faut pas se méprendre, une petite entreprise est tout aussi intéressante pour un pirate informatique qu’une plus grosse. 

C’est pourquoi la sécurité de vos systèmes d’information doit être une priorité. La posture et les réactions de vos équipes seront déterminantes, elles peuvent protéger vos données comme les compromettre. 

Dans cette interview, Guillaume Boyer, pentester chez Agaetis, nous parle des enjeux autour de la cybersécurité, de l’importance des mots de passe et également des différents types de cyberattaques.

Guillaume Boyer, Pentester chez Agaetis

1/ Pour commencer, quels sont les enjeux actuels autour de la cybersécurité pour les entreprises ? 

La question qu’il faut avoir en tête n’est pas “vais-je me faire attaquer ?’, mais “Quand vais-je me faire attaquer ?”. Les entreprises sont confrontées à de multiples menaces. Du simple espionnage au vol et à la destruction de données, les conséquences d’une cyberattaque peuvent avoir un impact catastrophique sur l’image et la réputation de l’entreprise, notamment son économie. La productivité de l’entreprise chute fortement et les interruptions causées par l’indisponibilité des services informatiques peuvent entraîner des pertes financières.

2/ Les mot de passe constituent une première barrière contre les cyberattaques, avez-vous quelques conseils les concernant ? 

Les fuites de données, la puissance de calcul pour craquer un mot de passe, le phishing… Les mots de passe ne suffisent plus à protéger les données. De plus, les politiques de changement régulier de mots de passe dans les entreprises poussent les employés à utiliser des mots de passe facile à retenir (donc facile à deviner pour un attaquant). Il est donc nécessaire de mettre en place une authentification à deux facteurs. Il s’agit d’une méthode d’authentification forte. Les utilisateurs peuvent accéder aux ressources informatiques (ordinateurs, smartphones et même sites Web) en soumettant deux certificats d’identification distincts au mécanisme d’authentification.

3/ Quelles sont les attaques les plus courantes et quelles sont les techniques des pirates informatiques ? 

En 2021, il  y a eu plus d’attaques par « ransomware* » que pendant toute l’année 2020 (304,7 millions d’attaques les 6 premiers mois de 2021, contre 304,6 millions au total en 2020). Le risque de voir ses données chiffrées contre son gré est important, et il ne faut pas croire que parce que l’on est une petite ou moyenne entreprise on n’intéresse pas les pirates. 57 % des attaques par ransomware touchent des entreprises de moins de 250 salariés et 71 % des TPE et des PME qui font l’objet d’une cyberattaque ne s’en remettent pas…

Les pirates informatiques  utilisent différentes méthodes pour attaquer une entreprise. Il y a bien sûr le courriel avec une pièce jointe vérolée, mais ils peuvent aussi rentrer sur un réseau en passant par une vulnérabilité de votre infrastructure informatique. Le mieux est de sensibiliser ses employés aux risques cyber.

*Les ransomwares sont des logiciels d’extorsion qui peuvent verrouiller votre ordinateur et demander une rançon en échange du déverrouillage de celui-ci.

4/ Avec la pandémie mondiale et le télétravail, quels sont les comportements à éviter pour nous protéger et protéger notre entreprise ? 

Durant le télétravail, les collaborateurs d’une entreprise doivent redoubler de vigilance, l’environnement sécurisé de votre entreprise n’est plus actif en télétravail : les personnes en télétravail peuvent se connecter via un ordinateur personnel mal protégé ou via une tablette familiale qui circule à la maison, exposant des données confidentielles à des personnes non autorisées. Sans compter que de nombreux logiciels tiers sont utilisés pour la visioconférence ou l’échange de messages instantanés. Ceux-ci peuvent également représenter des sources de danger. Il est donc impératif de sensibiliser aux risques et de mettre en place un VPN pour accéder aux serveurs de votre entreprise.

5/ Pour terminer, quel est l’intérêt pour une entreprise de sensibiliser ses collaborateurs autour des risques que peuvent représenter des cyberattaques ? 

En 2020 le CERT-FR (Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques) a enregistré une hausse de 255 % des attaques de ransomware par rapport à 2019, et la tendance est en hausse en 2021. Le risque d’attaques informatiques pour votre entreprise est donc non négligeable. Pour éviter cela il faut vous préparer et former vos collaborateurs aux menaces auxquelles ils font face.

Agaetis propose une formation à la fois théorique et pratique sur tous ces sujets. Grâce à ce stage interactif, aux quiz, aux preuves de concept, aux démos exposées tout au long de la formation, vos collaborateurs auront toutes les cartes en main pour éviter les pièges des pirates informatiques.

Un stage de recherche en data science à Tokyo, ça se passe comment ?

Vous vous demandez à quoi cela ressemble de réaliser un stage dans le domaine de la data science à l’étranger ? C’est l’expérience que Roxane, étudiante doctorante chez Agaetis, a pu réaliser !

Dans le cadre des mes études en école d’ingénieur à l’ISIMA, j’ai eu la chance de faire mon stage de deuxième année à Tokyo, où j’ai donc passé 5 mois. J’ai effectué ce stage à l’Institut National d’Informatique (NII), institut de recherche au cœur de Tokyo, et plus précisément dans l’équipe de recherche travaillant sur le projet “Recettes de Cuisine sans Frontières” (CRWB – Cooking Recipes Without Borders), sous la direction du Pr Frederic Andres. 

NII et Flavorlens, qu’est-ce que c’est ?

Le NII – National Institute of Informatics (Institut National d’Informatique) est un institut de recherche publique japonais créé le 1 er avril 2000, qui étudie l’ensemble des domaines touchés par l’informatique (sciences sociales, robotique, mathématiques appliquées, sécurité, théorie des graphes, intelligence artificielle, économie, etc.). Le NII a pour but de faire avancer la recherche en informatique et de faciliter l’accès du grand public aux avancées scientifiques. 

Un des projets de l’équipe CRWB est une application de réseau social appelée Flavorlens. Il s’agit d’une plateforme de partage d’expériences culinaires qui a été mis à disposition des utilisateurs d’appareils Android et iOS en août 2018. Elle permet aux utilisateurs de poster des observations avec une photographie du plat, un titre (nom du plat) et une description accompagnée d’une note. 

Logo Flavorlens

Le but de ce stage était de travailler sur l’extraction de communautés, sur des graphes représentant des données générées par les utilisateurs de Flavorlens. Même si l’application est disponible depuis quelques années, les données qu’elle génère n’avaient pas encore été analysées. L’extraction de communautés a pour objectif d’effectuer une première analyse du comportement des utilisateurs, qui pourra ensuite être utilisée de manière régulière via un système de recommandations.

Si l’utilisateur a dégusté le plat dont il fait la revue dans un restaurant, il peut en indiquer l’adresse ainsi que le prix. Dans le cas contraire, il peut aussi indiquer que le plat est fait maison. Les autres utilisateurs pourront alors sauvegarder ce plat dans une liste de favoris « à essayer plus tard » s’ils veulent à leur tour y goûter. 

L’originalité de Flavorlens ? Ce réseau social a été conçu spécialement pour le partage d’expériences gustatives. Son originalité repose sur le fait que l’utilisateur peut ajouter des tags d’arômes aux photographies, ce qui lui permet de communiquer le goût ou même la texture du plat. L’application se distingue aussi des autres plateformes de revue de restaurants par son fonctionnement : elle permet de donner son avis sur un plat précis plutôt que d’évaluer le restaurant dans sa globalité. Les clients n’expérimentant pas tous les plats de la carte, ce mode d’évaluation paraît plus pertinent. Les utilisateurs ont aussi la possibilité d’interagir entre eux via les observations en les aimant ou en les commentant. Ils peuvent aussi s’abonner à d’autres utilisateurs pour voir toutes leurs revues. 

Travailler au NII

Bâtiment du NII

Les projets de recherche au NII peuvent aussi bien concerner des sujets théoriques que des applications concrètes. Le NII étant un centre de recherche inter-universitaire, il coordonne les relations entre les institutions académiques et le monde de la recherche, des équipes internationales de chercheurs y cohabitent également. On retrouve d’ailleurs cette ouverture à l’international dans les différents programmes du NII, comme les partenariats MoU – Memorandum of Understanding (Mémorandum d’entente) avec diverses universités et écoles d’ingénieurs dans le monde, ou encore le JFLI – Japanese-French Laboratory for Informatics (Laboratoire Franco-Japonais pour l’informatique), qui est un laboratoire mixte (Unité CNRS Mixte Internationale 3527).

Comme le NII entretient des partenariats avec des universités partout dans le monde, un grand nombre de stagiaires et doctorants internationaux travaillant sur un large éventail de sujets s’y retrouvent. Même si les méthodes et rythmes de travail sont différents selon les équipes, toutes évoluent dans un environnement multiculturel. 

Le projet

Flavorlens n’a pas encore de système de recommandation ou de création de communautés fortes : même si les utilisateurs peuvent s’abonner entre eux, ils ne peuvent pas créer de groupes fermés ou privés pour partager leurs expériences avec un nombre restreint d’utilisateurs. Dans ce contexte, mon stage abordait donc le problème de l’extraction de communautés.

Graphe avant extraction

La méthode d’extraction de communautés mise en place peut être découpée en 4 étapes:

  • Étape 1: Extraire les communautés avec une méthode concentrée sur le principe de mutualité. Ceci permet d’obtenir un graphe avec des clusters possédant un grand nombre de connexions mutuelles internes et très peu de connexions avec les autres clusters.
Etape 1
  • Étape 2: Regrouper les nœuds fantômes et satellites respectivement dans une communauté fantôme et une communauté satellite. Un nœud fantôme est défini comme un nœud du graphe n’étant connecté avec aucun autre nœud, un nœud satellite est défini comme un nœud du graphe connecté de manière mutuelle avec aucun autre nœud. Ces deux communautés sont justifiées par le fait que leurs membres expriment un comportement similaire sur le réseau social.
  • Étape  3:  Séparer la communauté satellite en deux communautés qui contiennent respectivement les nœuds satellites qui possèdent des arcs entrants et sortants.
  • Étape  4: Créer une classification hiérarchique en deux étapes pour les deux communautés générées à l’étape 3. Premièrement, en créant des communautés fondées sur le cluster sur lequel les nœuds satellites sont connectés. Tous les nœuds satellites connectés à un même cluster se retrouveront donc dans une même communauté. Dans un second temps, un processus de fusion itératif des sous-communautés satellites créées est exécuté: à chaque itération, les deux communautés les plus similaires fusionnent. Le processus itératif se termine quand toutes les communautés satellites ont fusionné en une seule communauté regroupant l’ensemble des nœuds satellites du graphe. Comme il est souvent impossible de savoir à l’avance quand arrêter le processus de fusion pour avoir les communautés les plus pertinentes, chaque itération du processus est sauvegardée dans une classification hiérarchique où il est possible d’accéder à toutes les combinaisons de communautés créées par le processus.
Etape 4

Opportunités et conclusion

Une partie de mon temps de travail au NII a été consacrée à assister à des présentations de chercheurs travaillant ou en visite au NII lorsque le sujet pouvait être intéressant pour le projet CRWB ou pour ma formation. Une semaine a en plus été dédiée à participer à la formation Scientific Communication in Practice (Communication Scientifique en Pratique), organisée par EURAXESS Japon et ELSI. Cette formation était centrée sur la découverte des différents types de subventions disponibles pour les chercheurs européens et les chercheurs au Japon, l’écriture académique en anglais pour les publications scientifiques, mais aussi des demandes de subventions. Moins académique, cette partie du travail était également importante et intéressante; elle m’a permis de prendre conscience des outils et fonds disponibles pour le financement des chercheurs en Europe et au Japon, mais aussi de mettre en œuvre et développer d’autres compétences comme la vulgarisation et la communication scientifique.

J’ai aussi eu l’occasion de présenter mon travail et le projet Flavorlens à plusieurs occasions, notamment pendant la journée portes ouvertes du NII mais aussi lors d’une conférence à Würzburg en Allemagne.

Ce stage a donc été pour moi une excellente occasion de découvrir le monde de la recherche, ce qui m’a permis de me conforter dans ma décision de poursuite d’études en doctorat. Cette expérience culturellement enrichissante m’a de plus beaucoup apporté d’un point de vue personnel. 

Agaetis et Sparkle, un vrai partenariat sur les pays francophones pour former à la cybersécurité sur une plateforme d’E training Cyber Range vendu par SPARKLE

La cybersécurité est au cœur des préoccupations. Agaetis et Sparkle, filiale du groupe TIM, ont décidé d’unir leurs forces pour proposer à leurs clients des services sur mesure de formation à la cybersécurité autour d’une plateforme de E-training “Cyber Range”.

Aubière, 2021 : Agaetis a signé un partenariat et une collaboration stratégique avec Sparkle, le premier fournisseur de services internationaux en Italie et parmi les dix premiers opérateurs mondiaux, pour proposer sa plateforme de formation en cybersécurité en France et dans les pays francophones.

Agaetis devient donc formateur et distributeur de cette solution dans ces pays. 

“Nous sommes en mesure de proposer Cyber range sur les pays francophones. Déployée sur plusieurs continents, la plateforme Cyber Range de Sparkle permet de suivre des scénarios d’attaques réelles sur une infrastructure virtualisées. On retrouve sur la plateforme les plus grands constructeurs en cyber sécurité. Elle s’adresse aux équipes de sécurité, SOC, CERT que l’on soit du côté BlueTeam ou RedTeam” déclare Cédric Lamouche, expert en cybersécurité chez Agaetis.

Grâce à cette coopération, Agaetis apporte son expertise, son expérience dans la cyber sécurité pour proposer des formations sur un secteur confronté à des difficultés de recrutement et de qualification de profils. Leurs experts techniques et formateurs seront en mesure d’accompagner les entreprises tout au long des formations pour réaliser et réussir les différents challenges proposés par la plateforme.

La plateforme Cyber Range a de nombreux avantages et permet aux entreprises, le désirant, de se challenger face aux nouveaux défis autour de la cybersécurité.

“Un des principaux avantages de Cyber Range est l’entraînement en mode SaaS dans une infrastructure totalement virtualisée, un navigateur suffit pour s’exercer. Ce sont, en plus, plus de 50 scénarios d’attaques réelles (ransomware, ddos, xss, rce, zéro day …) qui sont proposés, couvrant ainsi un grand périmètre d’action. Plusieurs niveaux de difficultés permettent également de personnaliser l’entraînement en fonction des objectifs et des compétences des collaborateurs. Autre spécificité de la plateforme : un formateur est présent et dédié à 100% à l’accompagnement des stagiaires. L’offre de service proposée par Sparkle permet donc de fournir des solutions adaptées à tous et surtout dans les meilleures conditions.” déclare Cédric Lamouche. 

Sparkle est une entreprise internationale dont la mission principale est de fournir aux entreprises des solutions intelligentes pour leur permettre de réaliser leur transformation numérique. La sécurité est l’un des principaux aspects de l’innovation pour lesquels les attentes sont élevées et sur lesquels Sparkle se concentre avec une approche large. Une des façons de réduire le temps consacré à atteindre le marché et ses clients est de mettre en place des accords de partenariat avec des entreprises locales, des acteurs reconnus et avec une forte connotation « innovation ». Agaetis possède toutes ces caractéristiques clés, un élément essentiel du partenariat.

A propos d’Agaetis : Basée à Paris, Lyon et Clermont-Ferrand, Agaetis est la filiale conseil Data et Innovation du groupe Novencia. Il s’agit d’une grande famille de 400 personnes. Agaetis est une entreprise qui porte des convictions et assume ses choix de s’engager pour les secteurs qui façonnent notre environnement de demain : la santé, l’agriculture, l’industrie, la mobilité, la santé et l’énergie. Leurs partenaires et références sont la base de leur expérience, c’est leur force pour conseiller et apporter des solutions pertinentes. Pour plus d’informations sur nos offres autour de la cybersécurité et plus particulièrement Cyber Range vous trouverez une vidéo de démonstration ici, rendez-vous sur : www.agaetis.fr

A propos de Sparkle : Propriété du Groupe Tim, Sparkle en est l’opérateur mondial, premier fournisseur de services internationaux en Italie et parmi les dix premiers dans le monde, elle possède plus de 600000 km de fibre courant de l’Europe à l’Afrique, les Amériques et l’Asie. En tirant parti de ses plateformes IP, Data, Cloud, Data Center, Mobile Data et Voice, Sparkle offre une gamme complète de solutions TIC aux entreprises, aux fournisseurs de services Internet, aux OTT, aux lecteurs de médias et de contenus, aux fournisseurs de services applicatifs ainsi qu’aux opérateurs fixes et mobiles. Sa force de vente est  répartie dans le monde entier et touche 33 pays.

Pour en savoir plus sur Sparkle, suivez ses profils Twitter et LinkedIn ou visitez le site Web tisparkle.com.

Agaetis and Sparkle, a true partnership on Francophone countries to train in cybersecurity on an E training platform Cyber Range sold by SPARKLE

Cybersecurity is at the heart of concerns. Agaetis and Sparkle, a subsidiary of the TIM group and among the top ten global service providers, have decided to join forces to offer their customers tailor-made cybersecurity training services around an E-training platform: the “Cyber ​​Security Training Platform”.

Aubière, 2021 : Agaetis has signed a partnership and strategic collaboration with Sparkle, the first international service provider in Italy and among the top ten global operators, to resell its Cyber Security Training Platform in France and French-speaking countries. 

Agaetis therefore becomes a trainer and distributor of the solution in these countries.

“We are able to offer the Cyber ​​Security Training Platform in French-speaking countries. Deployed on several continents, Sparkle’s Cyber ​​Security Training Platform makes it possible to follow real attack scenarios on a virtualized infrastructure. The largest cybersecurity manufacturers are found on the platform. It is aimed at security, SOC and CERT teams, whether on the BlueTeam or RedTeam side”, says Cédric Lamouche, cybersecurity expert at Agaetis.

Thanks to this cooperation, Agaetis brings its expertise and experience in the field of cybersecurity to offer training in a sector facing difficulties in recruiting and qualifying profiles. Their technical experts and trainers will be able to support companies throughout the training courses to achieve and succeed in the various challenges offered by the platform.

The Cyber ​​Security Training Platform has many advantages and allows companies wishing to challenge themselves in the face of new challenges around cybersecurity.

“One of the main advantages of the Cyber ​​Security Training Platform is the use in SaaS mode on a fully virtualized infrastructure, a browser is enough to practice. In addition, more than 50 real attack scenarios (ransomware, ddos, xss, rce, zero days, etc.) are offered, thus covering a large perimeter of actions. Several difficulty levels also make it possible to personalize the training according to the objectives and skills of the employees. Another specificity of the platform: a trainer is present and 100% dedicated to supporting trainees. « The service offering offered by Sparkle therefore makes it possible to provide solutions adapted to everyone and above all in the best conditions », declares Cédric Lamouche.

Sparkle is an international company whose mission in the Enterprise market is to provide smart solutions to enable the digital trasformation. Security is one of the major aspects of innovation for which expectations are high and that Sparkle is focusing on with a wide approach. One way to reduce the time taken to reach the market and its customers is to set up partnership agreements with local companies, recognized players with a strong « innovation » connotation. Agaetis has all of these key characteristics, an essential element of the partnership, as well as the fundamentals for achieving business results.

About Agaetis : Based in Paris, Lyon and Clermont-Ferrand, Agaetis is the Data and Innovation consulting subsidiary of the Novencia group. This is a large family of 400 people. Agaetis is a company that carries convictions and accepts its choices to commit to the sectors that shape our environment of tomorrow: health, agriculture, industry, mobility, health and energy. Their partners and references are the basis of their experience, it is their strength to advise and provide relevant solutions. For more information, visit: www.agaetis.fr.

About Sparkle : Sparkle is TIM Group’s fully owned Global Operator, first international service provider in Italy and among the top ten worldwide, with a proprietary backbone of more than 600,000 km of fiber spanning from Europe to Africa, the Americas and Asia. Leveraging its global IP, Data, Cloud, Data Center, Mobile Data and Voice Platforms, Sparkle offers a full range of ICT solutions to Enterprises, Internet Service Providers, OTTs, Media and Content Players, Application Service Providers as well as Fixed and Mobile operators. Its sales force is active worldwide and distributed over 33 countries.

Find out more about Sparkle following its Twitter and LinkedIn profiles or visiting the website tisparkle.com.

L’approche Zero Trust, qui, où, comment, pourquoi

Si 2020 nous a bien enseigné une leçon c’est qu’il ne faut rien prendre pour acquis et plus particulièrement dans le domaine de la cybersécurité. 

Vikas Pandurkar, ancien de l’Insead et de l’école des Ponts et Chaussées, a travaillé pour des entreprises comme Tekelec, Cisco, Level3, Avni (racheté par Veritas), PulseSecure (racheté par Ivanti)… 

Il a créé Oxortis il y a 4 ans et a principalement travaillé avec des entreprises en B2B SaaS américains basés sur la côte ouest.

Ancien membre de l’équipe de l’ingénierie de Pulse Secure (leader mondial dans les VPN’s) pour concevoir, développer et mettre en œuvre la nouvelle plateforme basée sur l’approche Zero Trust, l’entreprise est désormais partenaire privilégié de cette nouvelle plateforme.

En quoi consiste cette approche, comment peut-elle aider les entreprises à sécuriser leur système d’information ? Vikas Pandurkar nous dit tout dans cet entretien !

Vikas Pandurkar

La cybersécurité dans le contexte de la Covid-19

Il y a eu un avant, un pendant et sûrement un après crise sanitaire. Pour le fondateur d’Oxortis, avant 2020 les entreprises étaient en capacité de maîtriser leur infrastructure grâce à leur périmètre bien défini. Cela se traduisait par des centres de données construits avec des stacks technologiques hétérogènes que les entreprises avaient rachetées et intégrées cela malgré un environnement qui devenait complexe. Ces différentes étapes avaient été gérées à un coût assez élevé, “la part de mobilité pour laquelle les entreprises avaient taillé leur infrastructure avoisinait 10-15%”. 

Or, la suite de l’histoire on la connaît : avec le confinement et une grande partie des effectifs à domicile, les entreprises ont dû investir dans de nouveaux équipements pour que les salariés puissent se connecter aux centres de données d’entreprise et travailler. 

2020 a aussi changé certaines méthodes de travail : “les entreprises ont souvent des applicatifs qu’ils consommaient en mode SaaS, ou hébergeaient dans des clouds types AWS, Azure, GCP etc.” 

Dans le contexte de la crise sanitaire, il était alors de plus en plus compliqué pour des DSI d’être certain qu’ils soient conformes aux normes RGPD ou aux politiques qu’ils avaient définis pour leur société. Répondre à « qui a accédé aux ressources d’entreprise, quoi (ce qu’on a vu, pris, volé…), quand, (cela s’est produit) et comment (on a été compromis) » devenait également un défi.

Les analystes Forrester, Gartner et autres ont d’ailleurs constaté qu’il y a plus de données sensibles à l’extérieur de l’entreprise (et non dans leurs centres de données) et il y a plus d’appareils personnels qui se connectent aux ressources de l’entreprise. Le télétravail est un facteur important de cette fragilisation, depuis le premier confinement, le nombre d’appareils, serveurs, ressources à provisionner et gérer a augmenté exponentiellement.

L’approche Zero Trust

Comme nous le savons déjà, la crise sanitaire que nous traversons a mis en lumière les nombreuses lacunes des systèmes de sécurité traditionnels. D’après une étude McAfee de 2020, il y a eu 50% de croissance en services dits cloud, 2 fois plus de trafic en cloud émanant des appareils non gérés par l’entreprise et 630% de croissance en événements d’attaques dans des environnements cloud. 

Le Zero Trust est un service de mise en place d’un socle, permettant une visibilité et un contrôle des 4 dimensions suivantes :

  • des utilisateurs
  • de leurs appareils (ceux donnés par l’entreprise ainsi que les appareils personnels des collaborateurs), 
  • de l’infrastructure qui héberge les ressources de l’entreprise 
  • des applications et des données qui se trouvent dans les diverses infrastructures qu’utilise l’entreprise.

“Nous proposons 3 services : 

  1. Nous aidons les entreprises à mettre en place une stratégie Zero Trust (indépendant de quelconque produit). Nous avons d’ailleurs une accréditation Forrester pour réaliser cette mission.
  2. Nous proposons des services d’onboarding pour la plateforme de Zero Trust d’Ivanti (anciennement PulseSecure).
  3. Mais aussi des services managés, également pour la plateforme d’Ivanti.

Tous types d’entreprise, indépendamment du secteur d’activité, doit protéger ses ressources.”

A ce titre, Oxortis travaille depuis presque 2 ans avec Pulse Secure sur l’élaboration, le développement et la mise en marché de cette nouvelle plateforme. Ils proposent des services managés, leur équipe est basée en Inde dans un centre certifié ISO et CMMi (Capability Maturity Model Integration).

Les avantages de la méthode Zero Trust

Par rapport à l’actualité et au contexte de télétravail qui accroît les cybers risques, la méthode Zero Trust a plusieurs avantages.

Tout d’abord c’est un concept de sécurité qui exige que tous les utilisateurs, même ceux à l’intérieur du réseau de l’entreprise, soient authentifiés et autorisés avant d’obtenir l’accès aux applications et aux données. Une fois que ceci est fait, pour conserver l’accès obtenu, Zero Trust préconise la validation en permanence de la configuration et la posture de sécurité. “Pour un monde de travail de plus en plus à distance, le Zero Trust est nécessaire et urgent à mettre en œuvre”.

Pour Vikas Pandurkar “Zero Trust est un changement significatif par rapport à la sécurité réseau traditionnelle, il faut prouver à chaque fois que l’on a le droit d’accès à telle ou telle ressources. 

L’approche traditionnelle faisait automatiquement confiance aux utilisateurs au point d’exposer l’organisation à des risques pouvant venir d’acteurs internes malveillants et permettant ainsi aux utilisateurs non autorisés un accès étendu une fois à l’intérieur du système.”

Il précise néanmoins que l’approche Zero Trust n’est pas un produit ou un service. “C’est un chemin/framework/paradigme d’avenir qui devrait permettre aux entreprises de toutes tailles de sécuriser les 4 dimensions à protéger en permanence – utilisateurs, appareils, infrastructure, applications/données”.

Pour un peu de contexte, la confiance zéro est née du travail effectué par la Defense Information Systems Agency (DISA) et leur travail sur le concept de périmètre défini par logiciel (SDP – Software Defined Perimeter). Puis, ce travail a été officialisé et popularisé par la Cloud Security Alliance au cours de la dernière décennie. Un SDP incarne les principes de la confiance zéro au niveau du réseau. Il introduit des mécanismes pour contrôler l’accès au niveau du réseau à un système et pour demander l’accès et l’accorder. Un SDP est un réseau virtuel, profondément segmenté et centré sur les terminaux, superposé à tous les autres réseaux physiques et virtuels déjà présents.

SDP Architecture ; Source : Cloud Security alliance

L’approche Zero Trust sur le marché français

L’idée du Zero Trust est naissante en France, comme le montre la récente étude d’Opinionway commissionné par le CESIN, seulement 6% des 228 entreprises interrogées sont très engagées dans l’approche et 23% sont en train d’en mettre en place les premières briques. 

Comme tout nouveau concept, il est donc normal d’avoir à réaliser une phase d’évangélisation avant que les DSI s’approprient l’idée et l’adoptent. 

“On peut se demander : y a-t-il une alternative valable à Zero Trust ? D’autres approches existent certainement, mais elles n’apportent pas les résultats escomptés.” 

Vous l’avez peut-être lu, le gouvernement américain a décidé de mettre en place une sécurisation des ressources consistant aux utilisateurs, leurs appareils, les applications et des données qu’ils consomment et sur tout infrastructures. Cela est bien évidemment basé sur les principes de Zero Trust.

Quels sont les constats et les impacts de la crise sanitaire sur votre système d’informations ?

Suite à la crise sanitaire et aux changements que celle-ci a entraînés dans le monde du travail, plusieurs risques sont à essayer d’anticiper pour les entreprises :

  • Beaucoup d’entreprises étrangères ont franchi le pas et ont annoncé que les effectifs ne seraient pas obligés de revenir au bureau. « Anywhere workplace » veut dire que les DSI seront obligés de mieux sécuriser, veiller et contrôler en permanence, et donc d’être plus réactif pour limiter les incidents, qui ne cesseront d’augmenter. 
  • La récente étude d’AMRAE montre que l’indemnisation a triplé entre 2019 et 2020 et avoisine 217 millions d’euros. 87% des grandes sociétés sont couvertes et seulement 8% d’ETI d’après cette étude. “Il est fort probable que les assureurs demandent des primes contre des attaques cybers plus importantes à défaut de faire valider l’environnement sécurisé (par des experts) de l’entreprise et leur capacité à contrer des attaques.” On voit déjà la naissance de sociétés comme Cyberacuview, qui est un consortium de 7 assureurs, pour mieux organiser et structurer leur offre de cyber sécurité.    
  • Aussi, les segments et les sous-segments du marché de sécurité sont en constante évolution. Les experts sont peu nombreux sur ce dernier et ils s’arrachent à prix d’or et ne peuvent pas tout gérer. “On va devoir se reposer sur l’automatisation pour un certain nombre de choses, et on le constate déjà dans les nouvelles plateformes/ produits de sécurité”. 
  • Aussi, en cas de non-paiement de rançon, les personnes malveillantes peuvent menacer de divulguer des données sensibles (comme par exemple en Finlande avec l’entreprise Vastaamo) et le faire payer.

“Il vaut mieux se préparer en amont”

Pour Vikas Pandurkar il est urgent de faire quelque chose dès maintenant pour prévenir un maximum ces risques. 

Selon l’étude de Veracode titré « state of application security, 2020 », 83% des 85000 applications testées avaient au moins une faille de sécurité. La plupart en avaient beaucoup plus. L’étude démontre un ensemble de 10 millions de failles, et 20% de toutes les applications ont révélé au moins une faille de sévérité élevée. Un certain nombre de ces vulnérabilités ont été publiées par la communauté OWASP (Open Web Application Security Project) dès 2017. 

Selon des experts, des technologies permettent de faire un scan de tout internet (toutes les adresses IP4 public, +4 Milliards d’adresses IP) en moins d’une heure. Il suffit aux acteurs malveillants de trouver une vulnérabilité (CVE) qu’ils peuvent exploiter avant qu’une entreprise découvre qu’il y en a une chez eux. 

“Des entreprises qui revoient leurs processus de sécurité mensuellement, qui font des tests de pénétration tous les trimestres auront du mal à résister à un attaquant beaucoup plus réactif. Si les douze derniers mois nous ont prouvé quelque chose c’est bien cela. Si l’on creuse, les sociétés qui ont subi ces attaques se sont très probablement fié à leurs investissements en VPN’s, Firewall et d’autres produits adaptés pour un périmètre qui n’existe plus. Contre des intrusions préméditées et qui n’épargnent ni des sociétés privées, ni des institutions publiques, il vaut mieux se préparer – dès hier.”

Comment le zéro trust s’inscrit dans les prestations en cybersécurité d’AGAETIS et NOVENCIA ?

En tant que cabinet de conseil nous sommes toujours en veille d’approches complémentaires à nos savoir-faire et nous cherchons en permanence des méthodes et solutions pour augmenter le niveau de maturité aux risques cyber de nos clients.

Nos consultants interviennent en amont sur des phases d’audit/conseil pour évaluer la pertinence et le plan de charge à établir pour être en capacité de déployer une approche Zero Trust à grande échelle.

En septembre nous organisons chez Novencia un événement autour de la cyber sécurité où l’approche Zero Trust sera détaillée et nous présenterons des cas d’usages.

Plus d’informations sur notre offre en cybersécurité.

Comment améliorer les temps d’usinages et l’optimisation des conditions de coupes

Agaetis a travaillé en lien avec l’école d’ingénieurs Sigma Clermont et l’Institut Pascal sur un projet d’industrialisation d’une solution informatique issue des travaux de recherche.

Le projet ? Développer un code génétique permettant d’améliorer le temps de traitement des données autour de l’Usinage et l’Optimisation des conditions de coupes et ainsi améliorer l’interaction homme/machine. Le but était également de rendre cette solution évolutive, standardisée et exploitable par une entreprise industrielle. 

Pour concevoir cette application plusieurs thèmes ont été abordés par nos équipes : 

  • Algorithmie
  • Langage Python et C#

Ce projet s’est déroulé en plusieurs étapes, il a d’abord fallu analyser les thèses puis optimiser les algorithmes conçus par l’équipe projet de SIGMA Clermont ainsi que réécrire les développements initiaux pour être en capacité de livrer un nouveau logiciel plus performant développé en python. 

Pour revenir sur ce projet et mieux comprendre les tenants et aboutissant d’un tel code, Emmanuel Duc, responsable de la Chaire de Fabrication Additive à Sigma Clermont et Séverine Durieux, maître de conférences, ont accepté de répondre à nos questions !

En quoi consiste le travail de SIGMA Clermont et quelles sont vos spécificités ?

Nous développons une activité de recherche sur l’optimisation des processus via une démarche de prise de décision multi-critères avec un focus particulier sur la modélisation du processus décisionnel et son attitude vis-à-vis du risque. 

Nous l’appliquons à des problématiques de fabrication industrielle, de fabrication additive ou de fabrication durable intégrant l’ensemble du processus de la conception jusqu’à la fabrication des pièces, notamment pour l’aéronautique.

Notre activité de recherche porte sur l’optimisation des processus de fabrication en général. Souvent les clients industriels sont confrontés à un dilemme entre assurer la sécurité des processus et optimiser la performance en prenant un risque calculé. Notre approche consiste à modéliser les indicateurs clés de décision avant d’évaluer un grand nombre de solutions, pour en extraire les meilleures.

Outre l’optimisation des processus, cette approche apporte un réel bénéfice au niveau de sa compréhension et des critères de décision que chaque intervenant applique à son niveau.

Nous avons appliqué notre démarche dans le cas de l’optimisation de processus d’usinage de pièces aéronautiques, de l’optimisation du couple conception/fabrication pour des pièces de structure et pour la comparaison et le choix de procédés dans le cadre d’une fabrication durable.

Pourquoi avoir développé cet outil ? Quelles démarches et méthodologies ont été adoptées ?

Nous avons fait industrialiser la solution numérique de ce code génétique par Agaetis, car nous voulions le rendre accessible au monde industriel.

Cette approche nous permet d’élaborer des preuves du concept plus rapidement. 

Nous utilisons un algorithme génétique qui nous permet d’évaluer un grand nombre de solutions, que nous hiérarchisons avec une méthode de prise de décision multicritères. 

  • Dans un premier temps, nous modélisons le processus, c’est-à-dire que nous identifions les paramètres fondamentaux et les indicateurs de performance à évaluer. 
  • Dans un second temps, nous procédons à une hiérarchisation des critères grâce à des entretiens auprès des métiers. Ces entretiens permettent d’identifier les divergences de point de vue et participent à la construction d’un savoir faire commun. Ils sont particulièrement instructifs, car il y a peu de structures humaines de décisions où tous les intervenants ont un avis identique. 
  • Par la suite, nous adaptons le code générique développé par Agaetis pour valider la démarche d’optimisation retenue sur des cas industriels. La méthode est très souple et laisse la décision entre les mains de l’utilisateur final. C’est un accompagnement éclairé.

A qui s’adresse la solution et de quelle façon cette étude vous a-t-elle permis de développer un produit plus performant que les standards du marché ?

Cette approche s’adresse aux sociétés qui souhaitent mieux comprendre le processus décisionnel qui mène à faire des choix de processus de fabrication, ou qui sont confrontées à des compromis cornéliens. Notre produit est facilement adaptable, car il s’inscrit dans une démarche de co-développement avec l’utilisateur final.

L’outil est un support qui accompagne la démarche. Ces sociétés ont souvent réalisé des optimisations locales ou des innovations incrémentales et elles se rendent compte qu’elles doivent embrasser l’ensemble du processus pour avancer. Il nous est arrivé de collaborer avec un bureau d’étude et deux bureaux des méthodes de 3 sociétés différentes pour conduire une optimisation commune.

Pour industrialiser le projet, quel est pour vous l’intérêt de collaborer avec une structure comme Agaetis ?

Agaetis développe des solutions informatiques spécifiques depuis de nombreuses années, elle a donc une bonne connaissance des outils marchés, des technologies actuelles qui sont facilement interfaçables avec les SI des clients cibles. 

L’autre intérêt est de collaborer avec une société qui intègre dans ses développements la qualité de code qui permet de délivrer des logiciels bien documentés et robustes, ce dont les industriels ont besoin.

Pour nous c’est une structure souple et réactive, habituée à travailler avec des chercheurs et la proximité joue aussi un rôle important.

Atelier Craftsmanship chez Agaetis !

La crise sanitaire que nous connaissons depuis maintenant plus d’un an a modifié de nombreuses habitudes. La présence dans les bureaux étant restreinte et contrôlée, le télétravail est devenu une norme. Malgré tout, la présence sur site est parfois requise. 

Il faut alors trouver une solution pour s’organiser et ainsi limiter les passages dans les locaux. Chaque entreprise a alors élaboré une stratégie propre se traduisant par plusieurs actions : des groupes de discussion pour simplement se tenir informé de qui sera présent, des logiciels de gestion de temps, des tableaux de présence… Toutes ces solutions plus ou moins abouties permettent de s’organiser, mais quid de la question de l’évolution des mesures avec la levée de certaines restrictions ? 

Chez Agaetis nous avons décidé de mettre notre savoir-faire au service de cette problématique, pour essayer de faciliter la régulation du nombre de collaborateurs dans les bureaux avec une solution pratique et déclinable. 

Un atelier craftsmanship sur plusieurs jours a alors été organisé, dans cet article vous pourrez en découvrir la démarche, l’organisation, les problèmes que nous avons pu rencontrer mais également la suite que nous envisageons pour ce projet.  

Pourquoi un atelier Craftsmanship ? 

Au fil de réunions d’équipes full stack developer, nous avons décidé de faire un atelier autour du craftsmanship pour les raisons suivantes :

  • Expérimenter des concepts et technologies :
    • Faire suite à notre formation TDD, 
    • Expérimenter la Clean Architecture avec de l’architecture hexagonale,
    • Utiliser NextJS et GraphQL pour les diffuser plus largement au sein de notre équipe,
    • Faire du React pour avoir une technologie commune.
  • Partager entre développeurs une expérience commune :
    • Ne travaillant pas tous ensemble, nous voulions partager nos connaissances,
    • Faire du pair programming pour en voir les avantages et pouvoir partager rapidement nos connaissances.
  • Créer un outil qui pourra nous servir :
    • Création d’un outil de réservation des locaux d’Agaetis en accord avec la jauge Covid et les mesures de distanciation sociales en vigueur,
    • Recherches autour de l’UI et UX en fonction de nos capacités techniques.

Comment s’organise un atelier Craftsmanship ?

Nous avons demandé à Jean-Michel Gourbeau, coach agile, de nous aider pour l’organisation du projet. En amont, plusieurs étapes ont dû être réalisées afin de s’assurer que l’atelier se déroule dans les meilleures conditions possibles. 

Une première réunion de réflexion pour décider des technologies et concepts a alors été organisée puis un backlog a été créé ainsi qu’un projet dans Gitlab avec l’initialisation de dépendances et l’ajout d’un exemple d’architecture hexagonale. 

À la suite de ces premières étapes primordiales, un des développeurs de l’équipe et notre chargée de communication se sont occupés de concevoir des maquettes afin de pouvoir visualiser rapidement le rendu de l’application et avoir le plus d’éléments possible pour débuter l’atelier.  

La première étape était de prioriser le backlog sans définir le temps nécessaire pour chaque tâche : no estimate. La seconde était l’explication technique du projet avec React, Next JS et l’architecture hexagonale pour que tous les membres de l’équipe puissent avancer au même rythme en ayant les mêmes connaissances. 

Pour mettre en application la formation TDD reçue quelques semaines plus tôt nous nous sommes séparés pour faire du pair programming avec pour ambition de changer de coéquipier toutes les demi-journées et de nous retrouver tous les matins pour faire un point sur l’avancement du projet. 

Mais voilà, entre le programme souhaité et ce qui se passe vraiment il y a toujours des différences…

Attentes VS réalité

Un plan se déroule rarement à la perfection, il est normal de s’éloigner de la feuille de route et de rencontrer quelques difficultés, cela ne signifie pas pour autant que c’est un échec. Au contraire, se retrouver face à des difficultés nous pousse à nous adapter et à faire évoluer nos connaissances et le projet en lui-même. Voici les adaptations que nous avons dû faire, face à la réalité :

  • Le pair programming :
    • Il était en fait assez difficile de changer de binôme tant que la tâche en cours n’était pas terminée. Cela nous faisait perdre du temps, le nouveau binôme devant se familiariser avec la feature à réaliser et le code déjà écrit.  
    • Au final, sur trois jours d’atelier nous avons seulement changé deux fois de binôme.
  • Le TDD :
    • Il est plutôt difficile à mettre en place lorsqu’il s’agit de faire une partie qui concerne particulièrement l’affichage ou l’intégration de SSO par exemple. L’utilisation de Redux peut être une solution.
    • Nous avons dû abandonner les tests de rendu UI pour coller à notre fenêtre de 3 jours. 
  • Le remote :
    • Il nous a été plus difficile de suivre et donc de travailler en utilisant le pair programming,
    • Il nous également était moins facile de se concerter pour la coordination et l’organisation des tâches.
  • Les nouveautés et la complexité technique :
    • L’utilisation de NextJS, GraphQL et toutes les méthodologies, il a été difficile de tout mettre en place en même temps, 
    • La gestion du Server side Rendering de Next JS a ajouté de la complexité dans l’utilisation des libs, notamment pour le SSO. 

Et au final ?

Au bout des trois jours d’atelier nous avons réussi à finir toutes les tâches que nous avions classé en priorité 1. Le rendu est donc une application minimale mais fonctionnelle. 

En voici quelques éléments :

  • La connexion à l’application se fait grâce au compte mail du collaborateur,
  • Il est possible de réserver une date sur un calendrier (matin et/ou après-midi)
  • On peut voir les personnes présentes chaque jour dans les locaux 
  • Si le créneau souhaité est déjà réservé et que la jauge est remplie, une redirection est faite sur notre Slack permettant d’ouvrir une discussion et ainsi potentiellement libérer une place en échangeant sur les besoins de tous. 

Conclusion

Malgré les quelques problèmes évoqués plus haut dans cet article nous sommes satisfaits du rendu de l’application et surtout heureux d’avoir pu s’exercer à la pratique de pratiques craftsman et d’avoir eu l’occasion de les confronter à la réalité. 

Car plus que la livraison d’un outil pratique, cet atelier avait pour objectif de nous confronter à de nouveaux concepts et technologies pour tester nos connaissances et nos capacités à nous adapter.

Capture d’écran de la première version de l’application, le visuel de cette dernière est amené à évoluer avec les prochaines versions.

Nous allons continuer à développer d’autres features de l’application sur notre temps de veille et dans un atelier futur. Le but final de cet atelier étant de rendre notre solution Open Source pour répondre au potentiel nouveau besoin des entreprises. En effet l’ère du télétravail semble ouverte, peut être que la plupart auront des locaux ne pouvant pas accueillir tous leurs collaborateurs en même temps et il faudra donc organiser et réguler les présences sur site. 

Si vous avez des questions sur les méthodes utilisées ou si vous êtes juste curieux de notre projet, n’hésitez pas à nous contacter, nous nous ferons un plaisir de répondre à vos questions ! 

De l’importance de sortir de sa zone de confort en cybersécurité

Dans tous les métiers, si l’on veut être efficace et être à la pointe il est nécessaire de passer par des phases de dépassement personnel. C’est d’autant plus vrai en matière de cybersécurité. Ces dépassements peuvent prendre différentes formes mais ils ont un même objectif : se perfectionner. Il n’est pas si simple de pouvoir sortir de sa zone de confort dans le but de mieux performer. Plusieurs facteurs entrent en jeu, notamment l’envie, la possibilité de le faire, son organisation professionnelle et personnelle actuelle mais surtout la possibilité de se mettre dans des situations inconnues, inconfortables, ingérables !

Se dégager un temps de veille suffisant 

Dans les métiers de la cybersécurité il faut avant tout une très bonne base théorique pour rester dans de bonnes pratiques et justifier ses choix, mais il est indispensable de rencontrer des situations techniques nouvelles et différentes pour acquérir des réflexes, du conseil et de l’expertise. Il existe plusieurs exemples de métiers où il est très facile et dangereux de rentrer dans un mode de fonctionnement type “encéphalogramme plat”, comme analyste dans un soc, pentesteur, opérateur en sécurité opérationnelle. 

Ceci n’est pas lié aux capacités du collaborateur mais plutôt aux limites imposées par son temps disponible à aller chercher autre chose. Avoir un temps de veille dédié peut être suffisant pour s’améliorer, mais il faut se fixer des objectifs clairs et précis qui peuvent être insufflés par le management.

En cybersécurité rien n’est écrit, vous avez beau avoir déployé les résultats de la meilleure analyse de risques il y aura toujours un petit malin qui via une sécurisation oubliée ou une faille non détectée viendra mettre à mal des jours, des semaines de travail. Ce qui générera probablement une montée en stress et des comportements de collaborateurs inhabituels et imprévisibles. 

C’est pour cela qu’il me paraît primordial de préparer ses collaborateurs à ces choses inconnues, ces situations en dehors de leurs tâches habituelles dans le but de :

  • Leur donner plus de chance de dépasser leur fonctions ;
  • Acquérir des réflexes vitaux pour l’entreprise ;
  • Pallier des déficiences chez des collaborateurs ;
  • Monter en compétences sur des nouveaux sujets ;
  • Mieux se découvrir et accepter ses faiblesses ;
  • Renforcer l’esprit d’équipe ;
  • Améliorer sa posture et sa capacité à communiquer.

Ces choses peuvent paraître simples sur le papier, mais dans la réalité on est loin d’avoir les outils et les méthodes en entreprise pour apporter ces pratiques essentielles, qui pourraient permettre une meilleure efficacité dans la gestion des incidents, dans la remédiation et dans la surveillance. 

On entend souvent qu’il faut remettre l’humain au cœur des métiers de la cybersécurité et se détacher un peu plus des solutions technologiques, “dont acte” mais il faut savoir qu’aujourd’hui les charges de travail sont déjà importantes en temps normal dans les SOC et CERT, et on peut les qualifier d’intenses lors d’une crise majeure.

Éviter le syndrome de la feuille blanche 

C’est pour cela qu’il a été fait le choix chez Agaetis de proposer ces situations inhabituelles sous formes de scénarios d’attaques réelles couvrant un très large panel de compétences. Cette possibilité d’accéder à des événements inhabituels permet au stagiaire de réellement appréhender les choses sans stress et de prendre le temps nécessaire pour analyser le contexte afin de développer une stratégie par rapport à ses connaissances et son expérience. 

Le fait d’être dans une situation d’exercice sans conséquence directe sur de la production laisse au collaborateur la possibilité d’expérimenter, d’innover dans son approche, d’utiliser de nouveaux  outils et enfin de gagner en sérénité pour l’avenir. 

Le syndrome de la feuille blanche n’est pas possible dans ces entraînements. Il y a toujours un formateur qui veille sur les stagiaires pour leur donner les approches et  compétences théoriques permettant de les amener, par eux-mêmes, à réussir le scénario et débriefer ensemble sur la pratique à avoir, et ainsi de corriger les éventuelles erreurs.

Après vous avoir mis l’eau à la bouche avec la présentation de ce monde idéal pour vos collaborateurs en cybersécurité , je vous propose dans un premier temps de visionner notre vidéo sur le déroulement concret d’un scénario et reste à votre disposition pour rentrer plus en profondeur sur les larges possibilités d’usage de cette plateforme de formation.

Les jumeaux numériques et le secteur de la santé

Le jumeau numérique, ou digital twin, qu’est-ce que c’est ? Réplique numérique d’un processus, d’un système ou même d’un lieu ou d’un objet, il fonctionne en collectant une combinaison de données grâce à des IoT. Tous ces éléments donnent des informations sur le fonctionnement du dispositif représenté et permettent ainsi de prédire et d’organiser sa réponse face à certains types d’événements. 

Il existe en effet des outils qui permettent de répondre aux besoins d’anticipations des hôpitaux sur le volet capacitif mais aussi organisationnel.  Le Centre d’Ingénierie et Santé a réalisé de nombreux travaux sur le sujet, ce qui lui a ainsi permis de se différencier par rapport aux outils standards actuellement sur le marché. Alors quels sont les objectifs et les résultats attendus de ce projet ? Pour y voir plus clair, Vincent Augusto, directeur du CIS, et Jules Le Lay, doctorant travaillant sur le développement de l’outil, répondent à toutes les questions que vous pouvez vous poser !

Le projet : un jumeau digital pour dimensionner les lits d’hospitalisation

Mais tout d’abord, quels sont les objectifs de ce type de technologie ? L’utilisation d’un jumeau digital pour le dimensionnement en lits d’hospitalisation permet d’améliorer la qualité de l’accueil et de diminuer les temps d’attente des patients, leur parcours est donc optimisé et leur prise en charge est quant à elle définie par plusieurs critères : satisfaction patient, temps d’attente, nombre de transferts. 

Le digital twin améliore ainsi la capacité d’admission en évaluant la pertinence des investissements de façon virtuelle ou leur aménagement dans un objectif d’optimisation. 

Ce projet permet également de simuler les arrivées de patients suite à des phénomènes exogènes de type crises sanitaires, dans le but d’anticiper une organisation adaptée à la situation. Ceci permettra de dimensionner au mieux le nombre de lits d’hospitalisation et les transferts.

Le jumeau numérique ayant pour objectif de répondre à toutes ces problématiques est constitué des éléments suivants :

  • Un modèle de prédiction des flux de patients au sein de l’hôpital, des admissions programmées et non programmées de patients ;
  • Un modèle de simulation, permettant de simuler les parcours patients et de tester la configuration des moyens proposés par la direction hospitalière ;
  • Un modèle d’optimisation-simulation, permettant de proposer un dimensionnement optimal de l’hôpital sur un horizon d’un an en “lits chargés” (nombres de lits ouverts par service et par semaine et personnel médical associé).

CIS : des travaux de R&D 

Le Centre Ingénierie et Santé de Mines Saint-Etienne a développé un programme de recherche de 5 ans en collaboration avec le CHU de Saint-Etienne pour développer un jumeau numérique fonctionnel de l’hôpital à l’échelle d’un service de soins (service d’accueil d’urgence) et à l’échelle de l’hôpital en entier.

Les travaux préliminaires ont permis de construire et programmer des modèles de simulation à événements discrets, alimentés par des données du SI hospitalier en temps réel. Ils ont également permis d’expérimenter les modèles via un plan d’expérience d’occupation de l’hôpital et un outil d’aide à la décision sur les dimensionnements de services en lits.

  • Collecte et mise en forme des données (PMSI intra hospitalier) ;
  • Modélisation des parcours et injection dans le modèle de simulation ;
  • Dimensionnement par simulation/optimisation ;
  • Réalisation d’un prototype de digital twin pour valider la solution.

Le CIS et les jumeaux numériques 

Pour mieux comprendre l’intérêt des jumeaux numériques dans le secteur de la santé, Vincent Augusto et Jules Le Lay reviennent sur ce projet en en détaillant les objectifs, les spécificités et la démarche !

En quoi consiste le travail du CIS et quelles sont vos spécificités ?

VA : Le Centre Ingénierie et Santé est l’un des 5 centres de formation et de recherche de l’École Nationale Supérieure des Mines de Saint-Étienne. Il se focalise sur l’application de l’ingénierie pour résoudre des problématiques de santé. Nos équipes sont réparties au sein de 4 départements :

  • (1) la biomécanique des tissus mous, des textiles médicaux et des implants,
  • (2) l’ingénierie des biomatériaux,
  • (3) l’activité biologique des particules inhalées et
  • (4) l’ingénierie des structures de soin et des systèmes de santé. Ce projet de jumeau numérique a été développé dans ce dernier département.

Pourquoi avoir développé cet outil ? Quelles démarche et méthodologie ont été adoptées ? 

JLL : Cet outil a été développé dans le cadre de ma thèse sur l’amélioration du parcours de soin des patients multimorbides. Ces patients sont atteints de plusieurs pathologies chroniques et peuvent de ce fait avoir des parcours hospitaliers complexes. Nous avons décidé de développer un outil qui nous permettrait de simuler le passage de ces patients dans les différents services de l’hôpital, de tester les différentes organisations envisagées et de mesurer leur impact sur le reste de l’écosystème hospitalier. L’outil doit donc pouvoir simuler l’activité habituelle de l’hôpital et être modifiable pour y implémenter les différents changements.

Nous avons travaillé en collaboration avec le CHU de Saint-Étienne, qui nous a fourni les données de parcours des patients. Nous avons résumé ces informations à l’aide du Process Mining – un ensemble de technique de Data Mining dédié à l’étude des processus – sous la forme d’un graphe. Cela nous permet de générer dans le modèle des entités ‘patients’ ayant des parcours hospitaliers vraisemblables. Les modifications imaginées par les professionnels de santé sont implémentées et on analyse les résultats ensemble.

VA : Ce projet fait suite à une collaboration de longue date avec le CHU de Saint-Etienne, notamment sur les parcours de soins des personnes âgées (organisation du service de gérontologie, mise en place d’une « hotline » gériatrique, etc.).

De quelle façon l’intelligence artificielle vous a-t-elle permis de développer un produit plus performant que les standards du marché ? 

JLL : L’utilisation du Process Mining nous permet d’incorporer à l’outil de simulation une grande variété de parcours hospitalier, et d’introduire une plus grande part d’incertitude dans les scénarios de simulation tout en restant réaliste dans les parcours générés. Il est possible de se concentrer sur les parcours les plus représentés et faire abstraction des autres en jouant sur les paramètres des algorithmes. C’est un excellent moyen de représenter la réalité du milieu hospitalier, où chaque patient est unique.

VA : Nous sommes pionniers dans l’application de techniques de process mining sur des données médicales, notamment sur les bases de données médico-administratives telles que le PMSI (Programme de médicalisation des systèmes d’information) et le SNIIRAM (Système national d’information inter-régimes de l’Assurance maladie). Ce projet constitue une suite naturelle de nos premiers travaux en la matière en collaboration avec la société HEVA, qui ont conduit au développement de premiers outils fonctionnels d’application du process mining sur des données du Health Data Hub.

Pour industrialiser le projet, quel est pour vous l’intérêt de collaborer avec une structure comme Agaetis ?

JLL : Notre collaboration avec Agaetis sur ce projet nous permet de développer la flexibilité de l’outil. Nous pouvons ensemble aller plus loin que son utilisation en tant qu’outil de recherche sur un problème défini et l’adapter à un grand nombre de situations et de structures.

VA : Cette collaboration s’inscrit dans les objectifs de transferts de l’École, et du CIS en particulier. En effet, la mise en application des prototypes développés dans le cadre de la recherche fait partie de nos missions, et Agaetis est le partenaire idéal pour l’industrialisation de solutions logicielles tel ce prototype de jumeau digital.

Pour Agaetis quel est l’intérêt de s’impliquer dans ce type de projet ?

José Alba (responsable de l’offre digital manufacturing) : Nous poursuivons plusieurs objectifs à travers ce type de collaboration : 

  • Nous souhaitons être de plus en plus présent dans le secteur de la santé ;
  • Industrialiser des prototypes ou des outils issus de la recherche permet à nos équipes de collaborer avec des enseignants-chercheurs et de délivrer des solutions innovantes, en avance de phase sur les technologies du marché ;
  • Être différenciant sur nos activités grâce au transfert de connaissances des travaux issus de la recherche que nous pouvons nous approprier et les porter sur d’autres type de projets ;
  • Proposer à nos équipes en interne des sujets toujours très innovants et conserver ainsi une dynamique technologique.

Les problématiques du SEO avec les Single Page Apps (SPA) et leurs solutions

En 2021 on ne présente plus le SEO (“Search Engine Optimization”). Véritable moteur pour de nombreuses entreprises (e-commerce, référenceurs spécialisés…), il peut aussi être un gros plus pour n’importe quel autre type de société, pour se faire connaître et/ou obtenir des offres commerciales, etc.

Optimiser son placement sur les moteurs de recherche est tout un domaine d’expertise… Pourtant extrêmement peu enseigné en école et parfois peu pris en compte lors des développements. 

C’est ainsi qu’il arrive que des ratés aient lieu, et ce notamment avec les SPA (sous React, Angular ou encore VueJS). En effet, ces technologies récentes ne sont pas vraiment compatibles par défaut avec les robots de parsing des moteurs de recherche. Nous allons voir en quoi et pourquoi, mais aussi les solutions à mettre en œuvre pour contrer ces problématiques.

Pourquoi les moteurs de recherche ont du mal avec les SPA ?

Mettons nous du point de vue de Google, Bing et les autres : il faut mettre en place un robot qui va parcourir tout internet, chaque jour idéalement pour être au plus près de l’actualité. Un tel robot n’est pas gratuit, et encore moins s’il doit “parser” du JavaScript.

En effet, historiquement une page Web se récupère avec une simple requête réseau. Pour un robot, il suffit ensuite de lire le contenu puis l’ajouter dans une base de données, ce qu’on appelle en SEO l’indexation. S’y ajoute l’algorithme de placement pour comparer différents sites sur un même sujet et ainsi déterminer qui décroche la position n° 1, le graal en référencement. Et c’est tout ! Le coût de ces opérations est quasi-équivalent au temps de l’appel réseau, soit un ordre de grandeur d’environ 50 à 200 millisecondes. 

Dans le cadre d’une Single Page App au contraire, en plus de récupérer ce document HTML, il faut aller chercher les dépendances qu’il renseigne : les fichiers JavaScript, puis les exécuter dans un moteur JavaScript… que l’on appelle plus communément un navigateur. Une fois le tout fait, ça y est, le robot peut indexer le contenu. L’ordre de grandeur en temps passe ainsi ici à la seconde, voire la dizaine de secondes. Il faut aussi compter le coût en processeur et mémoire pour exécuter le JavaScript… Pour faire simple, on n’est plus du tout à la même échelle !

Concrètement quel est le risque en se lançant sur une SPA en 2021 d’un point de vue SEO ?

C’est la raison pour laquelle il semble qu’hormis Google, aucun moteur de recherche n’indexe les applications JavaScript. C’est-à-dire que le site ou l’application ainsi mise à jour vers ces nouvelles technologies, depuis un monolithe classique par exemple, disparaîtra complètement des radars (hors celui de Google) !

Pour faire cette affirmation, chose toujours compliquée en SEO, je me base sur une étude en conditions réelles faite en 2017, dont voilà la conclusion en une image (qui est toujours valide mi-2021) :

À noter qu’Angular 2 avait à l’époque un problème, même avec Google, ce n’est probablement plus le cas pour la dernière version de ce framework actuellement (source de l’étude et vous pourrez trouver le test en conditions réelles ici, toujours accessible sur internet). Qwant ou Ecosia ne semblent pas avoir indexé ces applications non plus, l’intérêt c’est qu’on peut le vérifier par nous même !

“Oui mais Google c’est 90 à 95 % de part de marché” me direz-vous, ce n’est peut être pas vraiment une grosse perte ? Cela va dépendre de votre population cible. Si ce sont des personnes plutôt “geeks”, ces dernières auront tendance à plutôt utiliser DuckDuckGo ou autre moteur de recherche plus respectueux de la vie privée (une tendance qui prend de plus en plus d’ampleur de manière générale d’ailleurs). Si au contraire ce sont des personnes peu habituées avec l’outil informatique, il est plus probable de les trouver en grand nombre chez Bing, le moteur par défaut livré avec Edge et Windows. Tenir ce discours peut donc paraître assez risqué.

Je me base une nouvelle fois sur des données à ma disposition : je possède un blog où j’écris des critiques sur des films, des tutoriels sur jeux vidéo ou encore des articles de vulgarisation scientifique. Le thème est donc un peu “geek”. Or, un tiers des entrées ont lieu depuis d’autres moteurs de recherche que Google, on est assez loin des 90% de part de marché !

“Quid de l’avenir” ? Puisque les SPA fêtent leurs 10 ans et sont maintenant extrêmement populaires, il semble assez clair que la plupart des moteurs ne vont probablement pas chercher à supporter les coûts d’exécution du JavaScript avec leur robot, sinon ça serait déjà fait. Il vaut donc mieux chercher des solutions pour contrebalancer ce problème (le fait que ces solutions existent maintenant est peut être une raison de plus pour que ces moteurs ne cherchent pas plus loin).

À noter par ailleurs que tout partage de lien sur les réseaux sociaux (ou un Slack, etc.) affiche normalement une miniature avec une image et un peu de texte. Avec une SPA classique, ces miniatures sont entièrement vides pour la même raison que vue précédemment : Facebook ou Twitter ne vont pas s’embêter à exécuter un moteur JavaScript entier pour afficher une simple image avec une phrase. Exemple concret avec les images ci-dessous :

Une miniature classique sur Facebook.

La même miniature si Le Gorafi devenait soudainement une SPA du jour au lendemain sans adaptation : on a bien moins envie de cliquer ! Le titre, l’image ainsi que la description en gris ont disparu. Le même constat peut d’ailleurs se faire sur Google avec la petite description en dessous de chaque lien qui sera manquante.

Quelles solutions pour garder des pratiques modernes de développement avec le SEO ?

Heureusement les équipes et communautés derrière les frameworks et librairies pour construire les SPA ont bien eu conscience de ce problème et ont mis en place des solutions, qui sont maintenant clairement considérées comme fiables avec la nouvelle décennie. C’est ce qu’on appelle le “Server Side Rendering” ou “rendu côté serveur” (SSR). 

Cela peut sembler comme un retour en arrière à première vue, mais selon la technologie on se retrouve plutôt avec le meilleur des deux mondes : des applications hybrides avec un rendu côté serveur puis une SPA qui prend le contrôle une fois la première page chargée par l’utilisateur – ou un site statique, construit et généré avec les outils modernes de développement JavaScript.

Pour React les plus connus sont Next.js et Gatsby, qui sont maintenus par la communauté :

  • Le premier permet ce type d’application hybride, proposant en même temps tous les bénéfices en termes UX des SPA et des sites Web classiques. 
  • Le second cherche plutôt à concurrencer les CMS comme WordPress en offrant un site statique et les plugins correspondants. 

Pour Angular il faut regarder du côté d’Universal, maintenu par l’équipe du framework. Quant à VueJS, ils proposent une solution native à la librairie.

Dans tous les cas, ces solutions sont à prendre en compte et à implémenter dès le début des développements, on s’expose sinon à des coûts de migration qui peuvent être assez lourds. En effet ces frameworks agissent comme des surcouches aux outils pour construire les SPA, il faut donc effectuer pas mal de changements. Mais s’ils sont mis en place dès le début, le surcoût en développement sera quasiment invisible.

Conclusion

Le monde du développement Web a énormément évolué ces 10 dernières années. De nos jours même l’hégémonie de WordPress est remise en jeu par des frameworks comme Gatsby à travers React. Il y a quelques années, comme en 2017 lors de l’apparition d’Angular 2, le SEO était une problématique majeure de ces nouveaux outils qui empêchait leur utilisation universelle. Mais ce n’est maintenant plus le cas, lorsqu’on a conscience des changements à apporter par rapport aux frameworks “vanilla”. 

Les techniques de rendu SSR s’imposent en effet de plus en plus et à juste titre, car en plus du SEO, la magie de ces outils permet d’avoir un Web de plus en plus rapide et de plus en plus pratique dans son utilisation ! Le tout en conservant le confort de développement apparu il y a 10 ans avec les SPA.

REX : Mon premier challenge Codingame

Codingame est principalement un site d’entraînement au langage de programmation utilisé par les recruteurs. Mais il ne se limite pas seulement à cet univers de test et d’évaluation. Il existe également un système de challenge qui m’était jusque-là complètement inconnu. 

Pendant une semaine entière, un défi est relevé par la communauté. Le but ? Des bots/robots codés par les participants s’affrontent par niveaux ou ce qu’on appelle des ligues (bois, bronze, argent, or, legend).

Codingame, qu’est-ce que c’est ? 

Idée reçue

Codingame était déjà passé dans mon radar mais je n’avais, à l’époque, pas été convaincu par ses puzzles games servant principalement à tester nos compétences en langage de programmation. Mon avis a bien évolué et a dépassé cette idée préconçue que je m’en étais faite.

Le hasard d’une rencontre

Le hasard fait bien les choses car durant une de mes missions j’ai été amené à rencontrer une équipe de “vétérans” de Codingame. Ils m’ont alors présenté un plus large éventail des possibilités du site, avec des défis plus aboutis.

Les avantages

L’idée de pouvoir coder un bot pour un jeu compétitif en python était pour le moins séduisante. Surtout que le site a eu la bonne idée de proposer les librairies de nos jours indispensables : numpy et pandas.

Mise en place

Après cette redécouverte de la plateforme, je me suis joint à leur équipe pour participer quelques jours plus tard au Fall Challenge 2020.

Ce challenge d’une semaine a pour thème un jeu de plateau physique qui a, pour l’occasion, été codé par les équipes de Codingame.

“Le jeu se déroule dans un magasin de potions dans lequel se trouvent deux sœurs jumelles sorcières, chacune tentant de prouver qu’elle est plus douée que l’autre dans la préparation de potions. Elles ont organisé un petit concours : gagner plus de rubis que sa sœur en vendant des potions. Cependant, la hutte de sorcière où est situé leur magasin n’est pas très grande, elles doivent partager le même espace de travail et gérer les mêmes commandes. “

“Chaque joueur contrôle une sorcière. Chaque sorcière a accès à son propre inventaire d’ingrédients ainsi qu’à une liste de sorts qu’elle a appris. Ces sorts sont utilisés pour transformer un ensemble donné d’ingrédients en un autre.Chaque commande est une liste d’ingrédients nécessaires pour préparer une potion et gagner des rubis. Une partie se déroule sur plusieurs tours. À chaque tour, les joueurs effectuent une action simultanément.

Ingrédients : Il y a 4 types d’ingrédients, de valeur croissante. Les types sont indexés de 0 à 3” (source : Codingame).

Pour plus de renseignements sur les règles du jeu vous pouvez consulter cette vidéo de tutoriel (en anglais).

Déroulé du challenge

L’interface

L’IDE de Codingame : à droite la partie code qui est auto-remplie avec les informations essentielles pour récupérer les inputs et générer les outputs ; à gauche la fenêtre du jeu qui permet de suivre les parties étapes par étapes ainsi qu’une fenêtre de débogage.

Les ligues

Après avoir testé son bot contre une IA, on lance une série d’affrontements contre les autres participants pour calculer son score au sein d’une ligue (bois, bronze, argent, or et legend), qui s’achève contre un boss.
Si l’on est victorieux, on passe dans une ligue supérieure (si celle-ci est débloquée). L’ensemble des ligues n’est pas accessible dès le départ mais se débloque à un rythme d’une tous les 2 jours. À noter qu’une nouvelle ligue apporte de nouvelles règles. 

Il y a donc dans cette compétition un système régulier de validation pour passer à des niveaux plus élevés, ce qui donne l’occasion de perfectionner son code et discuter stratégie avec son équipe. D’où l’intérêt d’en avoir une !

Se familiariser avec les règles du jeu

Au début même les experts utilisent python ou un autre langage permettant de prototyper rapidement et se familiariser avec les règles et l’interface. Chaque challenge ou puzzle impose un format spécifique aux inputs et outputs, même si l’interface reste la même. Ce passage est le plus déroutant pour un novice.
Heureusement une fenêtre de log permet de comprendre étape par étape le résultat de notre algorithme.

Évolution des règles

Comme dit précédemment, l’avancement se décompose en ligues. L’évolution dans les premières ligues se fait assez rapidement. Mais tout se complique lorsque les ligues se débloquent avec l’ajout de nouvelles règles. 

Exemple : à partir de la ligue argent, un système d’achat de sort à contester avec l’adversaire est mis en place. Si on n’a pas adopté des bonnes pratiques de code en début de challenge ces ajouts peuvent obliger à tout réécrire.

 

Quelques conseils pour bien commencer !

  • De bonnes pratiques de code sont très efficaces pour ne pas perdre de temps.
  • Bien choisir son algorithme : a priori partir au plus simple quitte à brader les performances et le faire évoluer en fonction des nouvelles règles de jeu.  
  • Les performances : chaque boucle de calcul ne doit pas dépasser 80 ms, dans la précipitation j’ai oublié que les performances de la bibliothèque pandas sont très inférieures à celles de numpy.
  • Visionner les derniers matchs de notre bot mais également des adversaires, on peut par exemple “charger” un bot pour s’entraîner contre lui. 
  • Une semaine est un temps très court, il faut s’appuyer sur son équipe pour avancer rapidement sur les stratégies et les choix algorithmiques.
  • Ne pas hésiter à copier les données d’entrée dans son IDE préféré (pour moi  un notebook) et tester des fonctionnalités pour accélérer le débogage.
Interface pour visualiser nos derniers combats. Elle se paye le luxe d’avoir un système de replay intégré.

Aller plus loin

Score officiel

À la fin du challenge j’ai terminé en ligue argent malgré de mauvaises performances du code et une prédiction de l’algorithme avec seulement 3 coups d’avance. 

Ce challenge était plutôt compliqué si on compare mon score avec celui de mes collègues plus expérimentés que moi. Cela est surtout dû aux changements de règles, comme l’achat de sort, qui oblige à décomposer notre algorithme en 2 phases lors d’une partie.
Même si l’exercice demande beaucoup de temps pour espérer être performant, l’expérience est addictive !

Je décide de continuer en me fixant comme objectif le rang or… Puis quelques jours plus tard le rang legend.

Challenge en solitaire

Même le challenge officiellement terminé, les bots des participants continuent de s’affronter. On peut donc continuer à s’entraîner pour améliorer son score. 

Cette première expérience ajoutée aux informations récoltées dans les post mortems des participants m’a permis de mettre en place une approche beaucoup plus efficace. Je m’étais d’ailleurs fixé un autre challenge personnel : concurrencer des langages plus bas niveau avec python.

  • Création d’un simulateur simplifié du jeu en python à partir des données d’entrée (liste des potions et recettes).
  • Un code pour tester différents hypers paramètres lié à l’algorithme. 
  • Un nouvel algorithme de recherche en faisceau, le Beam search, plus performant (beam Search https://en.wikipedia.org/wiki/Beam_search).
  • Adapter mon code pour prédire les coups de l’adversaire.

Événement marquant

Si je devais ne citer un événement marquant, ce serait celui de mon passage contre le boss entre les ligues or et legend. Sa puissance/son score dépend également de ses victoires contre les autres participants. Après la semaine officielle, il a tellement gagné en puissance qu’il était loin devant les autres participants. Je restais systématiquement à la seconde place juste derrière lui… Frustrant.
Pour le vaincre  ma stratégie fut donc de faire varier les hyperparamètres de mon modèle  en fonction de sa stratégie et de relancer le fil des combats toutes les 15 minutes. Pas très subtil mais quelle satisfaction quand j’ai finalement atteint le rang légende !

Conclusion

En conclusion, ce type de challenge est addictif et j’ai personnellement atteint mes objectifs, voire plus en accédant au rang légende. En bonus je suis également arrivé dans les premiers sur les participants avec le langage python. 

Grâce à une méthode orienté numpy mon code a pu affronter des langage plus véloces comme C# ou C++, avec une prévision à 15 coups d’avance ce qui était largement suffisant. Je reviendrai d’ailleurs dans un prochain article sur l’utilisation de numpy. 

Si vous avez des questions sur les challenges Codingame ou si vous voulez simplement échanger autour de ce sujet, n’hésitez pas à nous contacter, nous nous ferons un plaisir de vous répondre ! 

Retour d’expérience sur la certification “Certified Kubernetes Administrator”

Si vous suivez un peu nos séries d’articles, vous savez que Agaetis a de fortes convictions au regard de Kubernetes, qui se place de plus en plus en tête des orchestrateurs de conteneurs.

Sans refaire l’historique de Kubernetes, ce dernier est désormais sous la coupe de la CNCF (Cloud Native Computing Foundation) qui a pour but d’aider au développement de technologies Cloud Native.


La certification dont il est question dans cet article est dispensée par la CNCF, et vise à valider les compétences techniques d’administration de clusters Kubernetes.

Cet article a pour but de faire un petit retour sur la CKA que j’ai passée en décembre 2020 dernier, nous verrons donc ensemble ce qu’est la CKA, pourquoi j’ai passé cet examen, comment je m’y suis préparé, ainsi que les petits points qui m’ont surpris et qui sont bons à savoir si vous désirez passer la certification.

Attention : Il m’est interdit de montrer publiquement les questions que j’ai eues lors de l’examen. 

La CKA en quelques chiffres

La CKA est un examen pratique, d’une durée de deux heures, composé de 15 à 20 questions, chacune donnant entre 3 et 15 points.

Il faut un total de 66 points sur 100 pour être certifié.
L’examen évolue régulièrement, d’anciens retours d’expérience parlent de 3 heures d’examen avec 77 points requis.

La correction des questions est totalement automatique, et vous obtiendrez les résultats environ 36 heures après votre passage.

L’examen suit également les évolutions de version de Kubernetes, ainsi il est important de faire de la veille sur les nouvelles fonctionnalités si vous ne les utilisez pas au quotidien.

La CKA est valable 3 ans à compter de la date d’obtention.

Si vous ratez l’examen, vous avez un an pour vous réinscrire à une autre session gratuitement.
En date du 28 mai 2019, selon la CNCF 9000 personnes ont passé l’examen et 1700 personnes l’ont obtenu, nous n’avons pas de chiffres plus récents, mais je pense que le ratio de succès est désormais plus élevé, le pourcentage de passage étant plus bas.

Pourquoi passer la CKA ?

Kubernetes est une technologie assez jeune et en constante évolution, sur laquelle nombre d’entre nous ont appris par eux même, c’est pourquoi cette certification semble être un bon moyen pour valider ses compétences et se donner confiance.

C’est également une garantie pour les entreprises et les recruteurs, même si la certification ne couvre pas tous les aspects de l’administration Kubernetes au regard de la complexité de ce dernier.

Pour une entreprise qui offre du service autour de Kubernetes, il est également intéressant d’avoir plusieurs employés certifiés car il existe une certification d’entreprise (KCSP) qui a pour prérequis d’avoir au moins 3 employés CKA, et qui permet d’être référencé sur la page du CNCF.

Conditions de l’examen

Ce qu’il est important de savoir dans le déroulement de l’examen, c’est le nombre de règles à bien respecter, elles sont toutes disponibles sur le site de la certification et dans vos mails d’inscription.

Celle qui me semble la plus contraignante est de n’avoir que deux onglets sur son navigateur, un sur la session d’examen, l’autre sur la documentation de Kubernetes.

Il n’est pas toléré d’avoir autre chose d’ouvert sur son ordinateur que son navigateur.

Lors de votre session, vous allez être monitoré à distance et la plupart des autres contraintes visent à garantir le bon déroulement de la session et éviter les potentielles fraudes, ainsi vous devrez être dans une pièce au calme, seul, etc.

Préparation technique

Bien que je ne puisse pas ici donner d’exemple des questions que j’ai eues, je vais faire un résumé des différents moyens pour se préparer que j’ai utilisés, et regrouper les différents conseils des autres retours d’expérience disponibles en ligne.

Valider ses compétences

Pour être à l’aise lors de l’examen, il est essentiel de bien comprendre Kubernetes dans son ensemble, c’est pourquoi le tutoriel de Kelsey Hightower Kubernetes the hard way est souvent conseillé.

Il permet de reconstruire de zéro un cluster, si vous y arrivez facilement alors c’est que vous êtes suffisamment à l’aise avec les concepts, si non n’hésitez pas à le faire plusieurs fois.

La problématique de ce genre d’examen est qu’il est difficile d’estimer à quoi vont ressembler les questions, sous quelle forme vont-elles être présentées.

C’est pourquoi une formation revient souvent sur le devant des retex, celle de Mumshad Mannambeth sur udemy : lien.

Cette formation est très intéressante car elle reprend tous les points du curriculum CKA, en expliquant dans le détail chaque concept.

En plus de cela, la formation propose des lab interactifs sur lesquels vous pourrez vous tester dans des conditions quasi identiques à celles de l’examen. Ces labs sont présent à la fin de chaque chapitre pour valider vos compétences, ainsi qu’à la toute fin de la formation avec plusieurs examens blancs.

Pour moi c’est cette partie interactive qui fait toute la valeur de la formation, et qui permet de ne pas arriver devant l’inconnu le jour J.

Udemy propose quasiment toujours des promotions à -90% sur les formations, vous pouvez attendre et payer la formation 15 euros.

Outils et habitudes

Si vous travaillez au quotidien avec Kubernetes, vous avez probablement des habitudes de travail qui ne sont peut-être pas adaptées à l’examen.

L’examen ne dure que deux heures, et il est essentiel de faire vite et bien.

Pour cela il faut abuser des commandes impératives, qui permettront de créer des objets rapidement et sans erreur de syntaxe.

Soyez également à l’aise avec kubectl explain qui peut remplacer la documentation dans certains cas, et bien sûr faites-vous des bookmarks pour les parties de la documentation essentielles que vous savez difficiles à retenir.

Le jour J

Comme j’utilise Kubernetes au quotidien dans mon travail et que je m’étais bien préparé avec les formations/exercices vus plus haut, j’étais assez confiant le jour de l’examen, bien qu’assez stressé.

J’ai installé ma salle d’examen dans les locaux de mon entreprise, je passais l’examen à 14h et suis arrivé dès le matin pour tout préparer et tester mon matériel.

Pour vérifier la compatibilité matérielle (micro/webcam) vous devez installer une extension à votre navigateur et faire un test via la page dédiée sur le portail d’examen.

J’ai deux pc avec lesquels je travaille en fonction des besoins, un Linux (Manjaro) et un Windows.

Ce jour-là, j’ai eu la bonne idée d’emmener les deux “au cas ou”, et c’est ce qui m’a sauvé la mise, car impossible de faire fonctionner ladite extension sur mon pc linux !
Cela aurait pu m’empêcher de passer la session d’examen .


Je vous conseille fortement de tester plusieurs jours à l’avance que tout fonctionne bien avec le réseau et l’ordinateur que vous utiliserez, car si vous êtes derrière un réseau d’entreprise certaines restrictions de port peuvent entraver le portail.

Vous aurez tous les détails dans les mails/pages d’informations.

Après ce petit cafouillage mon stress a augmenté, et une fois la session d’examen débutée j’avais peur de faire des erreurs de typo dans le nommage de mes objets.

Il se trouve que les questions sont proches des examens blancs de la formation udemy, et une fois le stress redescendu j’ai pu aborder la suite plus sereinement.

Il m’a fallu 1 heure pour compléter toutes les questions (sauf une pour laquelle je n’avais aucune idée de comment la résoudre), j’ai passé l’heure restante à bien vérifier mes réponses et repasser sur toutes les questions, ce qui m’a permis de voir une ou deux petites coquilles que j’avais oubliées.

Je vous conseille fortement de garder un petit temps pour relire en détails les questions (n’hésitez pas à bien scroller l’énoncé, parfois on peut se faire avoir sur une question plus longue qu’il n’y paraît), et revérifier vos réponses.

Conclusion

Pour finir j’aimerais vous faire part de mon ressenti personnel face à la certification.

Je suis ravi de l’avoir passée avec un score de 80/100, j’ai trouvé les questions de l’examen assez faciles, cependant les choses peuvent aller très vite et une erreur de typographie sur une question difficile aurait pu me coûter l’examen.

C’est pourquoi bien que la plupart des questions ne soient pas insurmontables, l’examen lui-même demande beaucoup de rigueur et de concentration.

Si vous êtes encore réticent à l’idée de passer cette certification, nous espérons que cet article vous a donné envie de sauter le pas et si vous avez la moindre question n’hésitez pas à nous contacter, nous nous ferons un plaisir de vous répondre ! 

Kafka Stream : Utiliser l’API Processor en plus de Stream DSL

Tout le monde a déjà entendu parler de Kafka et lu maints articles à ce sujet.  Tout le monde a testé les “consumers” et “producers”, tout le monde a développé un “stream” pour compter des mots… Mais lorsque l’on sort des sentiers battus, il est difficile de trouver des articles sur comment utiliser la Stream Processor API dans des cas spécifiques. Cette dernière permet d’écrire des Streams Kafka lorsque Streams DSL n’est pas suffisant. Ces API permettent de définir la Topology d’un stream représentant la logique métier à appliquer sur la donnée traitée..

Bien entendu, je pense qu’il faut bien réfléchir avant d’utiliser un outil d’une façon différente de ce pour quoi il a été conçu. La question que l’on doit se poser est “Est-ce que ma façon d’implémenter mon besoin est justifiée, est-ce que j’utilise le bon outil ?” (Il est toujours possible d’ouvrir des huîtres avec un tournevis…)

Quel est le besoin ?

Dans le cadre d’un projet client, des boîtiers installés sur des véhicules envoient des données captées sur ces derniers et sont transmises au format protocol buffer via le protocole MQTT sur des brokers en mode streaming.  C’est un cas d’usage standard qui est facile à mettre en place dans la majeure partie des cas. Cela jusqu’au jour où de nouveaux boîtiers ont leur propre logique : stocker la donnée pour l’agréger au format trajet avant de l’envoyer. 

Cela induit des messages volumineux qui doivent être découpés en sous messages par les boitiers lorsque leur taille dépasse la taille maximum autorisée par le broker pour un message ou que la qualité du réseau ne permet pas d’envoyer des messages trop volumineux.  De plus, ces messages peuvent être envoyés dans le désordre, sur une période plus ou moins longue et sans assurance de tous les recevoir1. Enfin, les données d’un trajet doivent être renvoyées à un tiers une fois le trajet reçu en un seul message reconstruit.

L’implémentation

Le processus

Le processus décrit dans le schéma suivant permet de valider l’envoi d’un trajet consolidé une fois qu’il est entièrement reçu. 

Il doit répondre aux deux cas suivants:

  • Le boitier envoie les données en mode streaming: les paquets ne font pas partie d’un trajet agrégé par le boîtier
  • Le boîtier envoie les données en mode trajet: le boîtier agrège les données d’un trajet et les envoie au broker une fois celui-ci clos. Si le volume de données d’un trajet excède une taille maximale autorisée pour un paquet alors il est découpé en sous messages.

Le contenu du message

Pour qu’il soit possible de savoir si un message est de type trajet, une information facultative doit être rajoutée dans le message (cf  .proto2). Le champs “Trip” est présent si le boîtier émet des données en mode “trajet”, et contient le nombre de paquets représentant le trajet. Cette information permettra de savoir si tous les paquets d’un trajet sont reçus.

message Trip
{
   required int64  start  = 1;
   required int64  end    = 2;
   required uint32 chunk  = 3;
   required uint32 chunks = 4;
}

message Header
{
   required int64 ts     = 1;
   required int64 device = 2;
   optional Trip  trip   = 3;
}

Reconstruire un trajet côté serveur

Comme évoqué précédemment, l’API Streams DSL de Kafka ne permet pas de gérer ce cas. De prime abord nous pourrions penser qu’il est possible de le gérer avec les Sessions Windows, ces dernières sont représentées par des périodes d’activité séparées par des périodes d’inactivité. Si les boitiers envoient les données en mode streaming il est conseillé d’utiliser cette fonctionnalité car elle correspond à la définition d’un trajet. Mais dans notre cas, le trajet est déjà construit par le boîtier et il faut le reconstruire côté serveur. 

Dans notre cas, nous considérons qu’un trajet peut être reconstruit côté serveur lorsque tous les paquets d’un même trajet sont reçus ; si le TTL d’attente de tous les paquets est atteint nous considérons que nous ne pouvons pas envoyer le trajet incomplet au tiers.

De plus, le stream utilisé pour reconstruire les trajets ne doit pas stocker toute la donnée, seulement les index des paquets reçus afin de ne pas avoir de messages de taille trop importante et d’informations inutiles. L’idée est de réduire l’impact mémoire des messages qui transitent par Kafka, dans notre cas seules les métadonnées sont nécessaires pour définir un trajet.

Pour répondre à cette problématique il faut donc utiliser l’API Processor et plus particulièrement son intégration avec l’API Stream DSL. Voici une liste des composants importants:

  • Un objet Trip définit par
    • un device (l’identifiant boitier)
    • une date de début de trajet 
    • une date de fin de trajet
  • Un objet Status qui pour chaque trajet définit:
    • les index des paquets reçus 
    • le nombre de paquets total 
  • Un (De)-Serializer (Avro ou JSON3) pour les objets Trip & Status, déjà fourni par les exemples Kafka
  • Un State Store pour associer à chaque clé (Trip) une valeur Status du trajet
Stores.keyValueStoreBuilder(
   Stores.persistentKeyValueStore("STORE-TRIPS"),
   Serdes.serdeFrom(TripSerializer, TripDeserializer),
   Serdes.serdeFrom(StatusSerializer, StatusDeserializer)
);
  • Un Transformer pour la logique spécifique de reconstruction d’un trajet.
package xxx;

import [...]
import com.google.protobuf.Message;

public class ChunkedTripTransformer implements ValueTransformerWithKey<Key, Message, Trip> {
  private static final Logger LOGGER = LoggerFactory.getLogger(ChunkedTripTransformer.class);
  // TTL autorisé pour avoir la liste complète des paquets composants le message
  private final Duration delta;
  // Store utilisé pour stocker le status de chaque trajet
  private KeyValueStore<Trip, Status> kvStore;
  private ProcessorContext context;

  public ChunkTransformer(Duration delta) {
    this.delta = delta;
  }

  @Override
  public void init(ProcessorContext context) {
    this.context = context;
    kvStore = (KeyValueStore<Trip,Status>) context.getStateStore("STORE-TRIP-STATUS");
    context.schedule(Duration.ofDays(1), PunctuationType.WALL_CLOCK_TIME, timestamp -> {
      KeyValueIterator<Trip, Status> iter = this.kvStore.all();
      while (iter.hasNext()) {
        KeyValue<Trip, Status> entry = iter.next();
        if (Instant.ofEpochMilli(entry.value.getStartDate()).isBefore(Instant.ofEpochMilli(timestamp - delta.toMillis()))) {
          // Suppression des trajets non reçu après expiration du TTL
          this.kvStore.delete(entry.key);
        }
      }
      iter.close();
      context.commit();
    });
  }

  @Override
  public Trip transform(Trip key, com.google.protobuf.Message value) {
    int chunk = value.getHeader().getTrip().getChunk();
    // Si le paquet reçu a un index de chunk incohérent il n’est pas traité
    if (chunk <= 0 || value.getHeader().getTrip().getChunks() < chunk) {
      return null;
    }
    // Si le trajet n’est composé que d’un seul paquet alors le trajet est complet
    if (value.getHeader().getTrip().getChunks() == 1) {
      return new Trip(
        key.getDeviceId(),
        Instant.ofEpochMilli(value.getHeader().getTrip().getStart()),
        Instant.ofEpochMilli(value.getHeader().getTrip().getEnd())
      );
    }
    Trip trip = new Trip(key.getDeviceId(), value.getHeader().getTrip().getStart(), value.getHeader().getTrip().getEnd());
    Status status = this.kvStore.get(trip);
    // Si aucun status n’est présent dans le store alors c’est le premier paquet reçu pour le trajet
    if (status == null) {
      this.kvStore.put(key, new Status(value.getHeader().getTrip().getChunks(), chunk));
    } else {
      // Un paquet du trajet est réçu mais ce dernier n’est pas encore complet
      if (!status.received(chunk)) {
        return null;
      }
      // Le trajet est complet il est donc émis et supprimé du Store
      if (status.completed()) {
        this.kvStore.delete(key);
        return key;
      }
      // Mise à jour du status existant pour le trajet
      this.kvStore.put(key, status);
    }
    return null;
  }

  @Override
  public void close() {
    // nothing to do
  }
}

Conclusion

Dans la majeure partie des cas l’API Stream DSL fournie par Kafka permet de répondre au besoin d’implémentation. Dans cet exemple, le fait d’utiliser un Transformer custom a permis de répondre à la problématique, mais dans certains cas il faut utiliser l’API bas niveau pour construire entièrement le stream en utilisant des Source, Processors et Sink. 

La définition de la Topology établie uniquement avec l’API processor permet une grande liberté d’implémentation mais s’avère verbeuse et contraignante. La couche d’abstraction fournie par l’API Stream DSL simplifie l’écriture des streams et la possibilité de mixer les deux API Processor & Stream DSL évite d’avoir à tout écrire avec uniquement des processors dans certains cas.

Dans cet article nous nous sommes focalisés sur un cas précis, mais lorsqu’est abordé un sujet avec Kafka, il faut commencer par travailler sur la modélisation des données, sur les clés et valeurs qui doivent transiter dans le broker. La clé d’un message est très importante pour le partitioning et un choix inadapté peut avoir des conséquences sur l’écriture des streams et des consumers notamment.

N’hésitez pas à nous contacter si vous avez des questions sur ce sujet ou sur Kafka en général, nous nous ferons un plaisir de vous répondre et d’échanger avec vous !

1 Le protocole MQTT avec un QoS 2 assure qu’un message est envoyé et est reçu une seule fois. Mais dans le cadre du projet les données sont envoyées avec une connexion GSM et certains véhicules roulant à l’étranger peuvent rester de longues périodes dans des zones blanches. (retour au texte)

2 Le .proto est le fichier qui définit le format des messages Protocol Buffer. (retour au texte)

3 Dans notre cas nous utilisons un Schema Registry avec des schémas Avro. (retour au texte)

Flutter 2 vient de sortir ! Mais au fait, c’est quoi ?

Il y a un peu plus d’un mois, le 3 mars 2021, Google a annoncé la sortie de la v2 de Flutter. Ce framework de développement d’applications multi-plateformes, dont la première version est sortie en Juin 2018, est encore peu connu malgré une adoption qui ne fait qu’augmenter. Dans cet article nous allons voir ce qu’il apporte, notamment dans un contexte de développement mobile.

Quelles sont les problématiques d’aujourd’hui dans le développement mobile ?

Il existe actuellement de nombreuses manières différentes de développer des applications mobiles. Chaque solution a ses avantages et inconvénients, d’où l’apparition de nouvelles au fur et à mesure des années. Flutter s’inscrit dans cette logique et est d’ailleurs à ce titre l’une des dernières technologies disponibles. Comparons-les rapidement !

Le développement natif

L’architecture d’une application native : les API de la plateforme sont directement appelées (affichage, API hardware etc…). Les Widgets sont les composants natifs à l’affichage (liste, bouton, texte etc), rendus dans le “canvas” du mobile.

La contrainte principale du développement natif est le besoin d’avoir 2 équipes pour gérer chaque plateforme, à cause des langages différents : Java/Kotlin pour Android, Objective-C/Swift pour iOS. Chaque fonctionnalité doit donc être développée 2 fois, avec son lot de tests et donc de bugs potentiels.

À l’inverse, l’avantage principal réside dans le fait d’utiliser les technologies prévues à l’origine pour faire des applications : meilleur support et accès aux dernières fonctionnalités intégrées des systèmes d’exploitation.

Le développement natif est une bonne option dans le cas où le cœur de métier est le mobile et lorsque la performance est la priorité absolue. Dans les autres cas, il peut être intéressant de se tourner vers une autre solution.

Les apps hybrides WebView (Cordova, Ionic…)

L’application hybride est écrite en HTML + JavaScript et utilise l’affichage des pages web du mobile. Elle communique avec l’hardware à travers le “pont” du framework.

Ces applications sont en réalité des vues web en HTML, rendues par le mobile, de la même manière qu’un navigateur. Elles utilisent un service fourni par le framework pour faire le pont avec les services bas niveau du téléphone (caméra, audio, position, bluetooth etc).
L’avantage principal est évidemment l’utilisation des technologies du Web : échelle de popularité différente, langage interprété permettant le hot reloading et partage de la même base de code pour les deux plateformes. Mais tout cela au prix de performances bien plus réduites qu’en développement mobile natif, puisque l’on passe ici par une Webview à l’affichage.

Les Progressive Web Apps

Cette technologie là est un peu différente. En réalité ce n’est qu’un site Web installable affiché à travers un navigateur, mais ce dernier cachant son interface pour donner l’impression d’une application normale. Les performances sont évidemment encore moins bonnes que les Webviews et le support des API hardware est implémenté à travers les navigateurs (sur iOS/Safari notamment il en manque quelques unes).

L’utilisation prévue n’est pas la même : ici cela sera plutôt pour pouvoir accéder à une application Web à travers une icône installable sur n’importe quelle machine. Vous pouvez trouver plus d’informations sur cette technologie dans notre article sur les PWA.

Les apps React native

L’application React Native est aussi développée avec les technologies du Web mais gère son propre affichage, en embarquant l’interpréteur JavaScript. Elle communique avec la plateforme entière à travers le pont du framework.

Apparu pour répondre aux problématiques des Webviews, c’est une solution “entre deux” : on code une vraie application en JavaScript qui utilise les vrais composants graphiques natifs, et un “bridge” relie ce monde avec celui de la plateforme native.

Vous pouvez lire notre article consacré à React Native pour plus de détails. Les performances sont meilleures que les WebView mais restent notablement inférieures aux applications natives, principalement au moment du démarrage, lorsque l’interpréteur JavaScript est lancé et les composants d’UI sont transpilés en composants natifs.

Flutter est heureusement la solution à toutes ces problématiques !

Flutter est différent, mais en quoi ?

Une application sous cette technologie, développée en Dart, gère son propre affichage et n’a pas besoin de passer par un pont de communication avec le monde natif.

Apparu en 2017 et officialisé mi-2018, Flutter se veut être la solution aux problématiques vues jusqu’ici : partage du code entre les plateformes sans que cela se fasse aux dépens des performances

Pour ce faire, comme nous le voyons sur le schéma, Flutter n’a besoin que du canvas de la plateforme native pour afficher ses propres widgets de rendus de l’UI, l’application n’utilise en effet pas ceux de la plateforme native. Elle a de même besoin d’un accès aux services hardware. Tout le reste est géré par le framework, sans besoin de “Bridge” de conversion.
“Tout est un Widget” est l’idée centrale de cette technologie, car ils composent l’UI : à la manière de React, chacun peut être imbriqué dans un autre selon le besoin ou être personnalisé à l’envie sans pertes de performances.

Qu’est-ce qu’un widget

Les widgets sont des “unités de vue” : ils décrivent un affichage et un comportement (bouton cliquable par exemple). Une action donnée peut changer leur état et ainsi changer l’affichage de l’interface.

Les Widgets Flutter sont fournis avec le framework et ne sont pas convertis en composants natifs, c’est la différence majeure avec React Native.
Puisqu’ils sont fournis avec Flutter et ne sont pas uniques selon la plateforme (Android, iOS…) il n’y a pas de problèmes de compatibilité, un des soucis parfois rencontrés avec React Native où il arrive de faire du code spécifique.

Différents exemples de widgets (source)

Qu’est ce que le Dart ?

Langage créé par Google en 2011, il a la particularité principale de pouvoir être compilé vers la plupart des langages machine ou transpilé en JavaScript. Ainsi, tout comme ce dernier qui est interprété, le Dart permet la même puissance de développement (hot reloading etc), mais avec les avantages en production d’un langage compilé (performances). Le meilleur des deux mondes.
Le langage est assez proche de JavaScript dans sa syntaxe et est de la même manière mono-thread, ainsi que de nature asynchrone (avec notamment l’utilisation des mots-clés “async” et “await”).

Du code Dart peut être compilé vers toutes ces architectures processeur ou transpilé vers du JavaScript (source).

Dart connaît une popularité croissante depuis quelques années, à noter que Google l’utilise pour créer leur nouvel OS “fushia”, dont le but à terme pourrait être de remplacer Android.

Avantages/Inconvénients par rapport aux autres solutions

Puisque Flutter n’a pas besoin d’utiliser un “pont JavaScript”, on revient à un temps de démarrage très proche des applications natives. De la même manière les performances globales sont bien meilleures, grâce aussi au fait que Dart peut être compilé en AOT en code natif

Ce dernier propose également un compilateur JIT, pour permettre une expérience de développement optimale avec le hot reload, similaire aux apps JavaScript.

Enfin, on note que Flutter dispose d’une solution CI/CD supportée par Google, alors que dans toutes les autres technologies vues dans cet article il faut utiliser des solutions externes comme Bitrise, si on le souhaite.

Au niveau inconvénients, il faut évidemment apprendre un nouveau langage, le Dart, qui n’a pas la popularité de JavaScript ou Java. Par ailleurs, les widgets peuvent être difficiles à appréhender au début, ça peut être comparable à une transition d’Angular vers React.  Ce sont les rares inconvénients de Flutter ! Bien entendu les performances restent distinguables de celles du natif mais l’écart est maintenant quasi invisible pour la plupart des utilisations.

L’écosystème du développement mobile ne s’y méprend pas : Flutter semble en effet avoir dépassé React Native en popularité vers mi-2020 (Google trends).

Les nouveautés de Flutter 2

Comme mentionné dans l’introduction de cet article, la version 2 de Flutter vient de sortir.

Une petite image qui résume les nouveautés de la version 2 (source)

Cette mise à jour comprend principalement la sortie du web stable. De la même manière que React Native, ce framework originellement conçu pour créer des applications mobiles permet maintenant de faire des applications Web. 

À terme, l’idée est de pouvoir concevoir des applications lourdes sous Windows, MacOS ou encore Linux, en plus des applications mobiles et Web, avec le même code. React Native a le même objectif, et les deux technologies semblent aller dans la bonne direction pour résoudre toutes les problématiques induites.

Conclusion

Flutter semble à la hauteur de ses promesses, alors qu’il n’a même pas encore 3 ans derrière lui. Ça ne présage que de bonnes choses pour l’avenir du développement mobile, mais aussi du développement multiplateforme de manière générale. On termine sur un benchmark pour voir concrètement les différences de performances. Voilà un rapide benchmark publié sur Medium où le natif, React Native et Flutter sont comparés sur un défilement d’images dans une liste.

Sur un Xiaomi Redmi Note 5.
Sur un Iphone 6.

Le constat est donc sans appel !

Les runtime Kubernetes CRI, deux alternatives à Docker

Récemment Kubernetes a annoncé déprécier Docker comme runtime CRI (Container Runtime Interface). S’en est suivi un mouvement de panique dans mon entourage sur la disparition de Docker. Au fil des articles de cette série, vous avez pu vous familiariser un petit peu plus avec les technologies de conteneurs, et constater que d’une part Docker a de multiples usages et que d’autre part il existe des alternatives convaincantes quelque soit l’usage qu’on en fait.

Dans cet article, nous allons parler des runtimes CRI, ces outils que Kubernetes (k8s pour les intimes) va utiliser pour créer les pods et lancer les conteneurs. Nous commencerons par un aperçu de ce qu’est le CRI de Kubernetes, nous verrons ensuite comment Docker s’intègre à Kubernetes avant de faire un rapide tour d’horizon des runtimes OCI qui existent aujourd’hui.

Le Container Runtime Interface de Kubernetes

Source : CNCF

Kubernetes est un orchestrateur de conteneurs que l’on ne présente plus aujourd’hui. Qui dit orchestrateur de conteneurs, dit que celui-ci doit démarrer des conteneurs à un moment donné. Cette tâche ainsi que l’implémentation concrète des pods est dévolue au runtime CRI.

Sur chacun des nœuds d’un cluster k8s se trouve la kubelet. Il s’agit grosso modo de “l’agent k8s”, il est chargé de la gestion des conteneurs sur son nœud. C’est donc à lui d’appeler le runtime CRI. En plus de gérer le cycle de vie des conteneurs, le runtime CRI gère également la gestion des images depuis une registry.

L’interface CRI utilise le protocole gRPC et les messages sont au format protocol buffer, un format binaire de Google.

Maintenant que nous en savons un petit peu plus sur le CRI, faisons un tour des runtimes CRI, en commençant par Docker.

Docker

Source : Docker

Docker permet de faire toutes les opérations attendues par un runtime CRI, sauf qu’il n’implémente pas l’interface CRI. Un composant a été ajouté dans le code de la kubelet pour explicitement gérer les conteneurs avec Docker : c’est le dockershim. C’est ce composant qui a été déprécié par Kubernetes.

Il faut rester vigilant au fait de ne plus utiliser Docker avec k8s : cela signifie aussi qu’il ne sera plus possible de faire du “Docker in Docker”, puisque les nœuds n’auront plus de socket Docker.

Il est donc maintenant évident que Docker n’est plus l’outil idéal pour s’interfacer avec Kubernetes. Mais docker n’est plus le monolithe qu’il était, il utilise containerd, qui lui est compatible avec le CRI.

Containerd

Source : CNCF

Containerd est un container engine utilisé par Docker qui est compatible avec le CRI. Il est le remplaçant le plus naturel à Docker dans un environnement k8s. C’est même une amélioration par rapport à Docker puisque l’on supprime un daemon et un composant du nœud.

Pour en savoir plus sur containerd, je vous invite à consulter l’épisode 2 de cette série sur les conteneurs.

Passons maintenant à l’autre runtime CRI bien connu : CRI-O.

CRI-O

Source : CNCF

CRI-O est un runtime CRI qui a la particularité d’être dédié à cette tâche, ce n’est pas un outil aux multiples usages comme Docker ou containerd. Il se veut léger et minimal.

Les principaux contributeurs de CRI-O sont Red Hat, Intel, Suse, Hyper et IBM. Il est le runtime par défaut d’Openshift (Red Hat),  SUSE CaaS platform et openSUSE Kubic entre autres.

Conclusion

Docker ne sera bientôt plus utilisable par Kubernetes, mais comme nous l’avons vu, containers et CRI-O permettent tous les deux d’assurer le même service. Ils sont tous les deux déjà utilisés en production.

Pour lire les précédents articles de notre série sur les containers : 

Digital Intelligence Way for Industry Institute : en route vers l’industrie 4.0

Le projet Digital Intelligence Way for Industry Institute (DIWII) est né sur le Campus Région Numérique, lieu physique de formation et d’échanges, c’est l’outil de tout un écosystème. Pour les entreprises et les industries c’est une offre de services indispensables pour dynamiser l’emploi, accompagner leurs transformations numériques et accélérer vers l’innovation. 

Situé à Charbonnières-les-Bains depuis janvier 2021, le campus va pouvoir accueillir un public varié d’environ 1500 étudiants, enseignants, collaborateurs d’entreprise et d’industriels.

Une réplique d’usine physique est présente sur le site associé à l’ensemble des technologies digitales, pour permettre aux entreprises de tester, expérimenter la numérisation de leurs processus de production avant de mettre en œuvre leur propre projet.

Le rôle du projet DIWII est de déployer des technologies à travers l’expérience, la complémentarité, les compétences des membres de son consortium.

Ce consortium propose une offre de service complète :

  • Centrée sur l’accompagnement de la mutation technologique des entreprises industrielles et sur la formation ;
  • Légitimée par une expertise scientifique de tout premier rang pour les domaines du numérique et de l’industrie.

Depuis plusieurs années, les membres du consortium s’efforcent de relever ce défi, DIWII rassemble plusieurs partenaires :

  • L’École des Mines de Saint-Étienne,
  • L’EM Lyon business school,
  • SIGMA Clermont,
  • 2MAtech,
  • Le Centre technique des industries mécaniques (CETIM),
  • Human To Data : consortium qui rassemble Phimeca engineering, Delta Mu  et Agaetis
  • Siemens
  • Bosch

Pour mieux comprendre les enjeux du projet DIWII, ainsi que ses tenants et aboutissants, les principaux acteurs de ce programme apportent dans cet article une réponse aux questions que vous vous posez ! 

Le consortium Human to Data, au sein du projet

Pour commencer, Jean-Michel Pou, président du consortium Human To Data (HTD), revient sur l’intérêt du projet.

HumantoData, partenaire du projet DIWII rassemble Agaetis, Deltamu et PHIMECA Engineering. Ce partenariat vise la mise en place d’une offre commune au service d’une digitalisation efficiente des industries, nous proposons ensemble de co-construire une solution collaborative reposant sur la combinaison de 4 savoir-faire :  

  • Pilotage de la performance industrielle ; 
  • Modélisation des phénomènes ;
  • Véracité des valeurs mesurées ;
  • Stratégie de traitement pour l’exploitation des données.

Pourquoi HTD a souhaité s’investir dans ce projet ? 

HTD est au cœur de la digitalisation et de l’exploitation des données, le campus Région du numérique est une vitrine des nouvelles technologies avec cette nouvelle capacité à exploiter des données à travers la Data Science. 

La place de HTD auprès du consortium DIWII s’est donc imposée comme une évidence.

Comment s’articule cette collaboration entre les partenaires ? 

Tous les acteurs de DIWII se connaissent de longue date. Les échanges entre nous étaient déjà fréquents, notamment sur les thématiques de l’Industrie du Futur. Nous avons, chacun, conscience de nos complémentarités, qui s’ajustent parfaitement dans la mission que DIWII s’est donné autour de la modernisation de l’industrie régionale. Chacun de nous apporte sa pierre à l’édifice de façon naturelle et c’est bien là toute notre force !

Quel est le rôle opérationnel de Human to Data dans ce projet ?

HTD est présent au CODIR de DIWII et participe aux décisions stratégiques et définit la feuille de route. Ces décisions sont prises dans un esprit coopératif : un membre, une voie. Nous sommes également présents dans les groupes « Projets » qui sont chargés d’élaborer les prestations/activités qui seront proposées aux entreprises de la région. 

C’est la complémentarité entre les écoles, les entreprises petites et grandes qui fait l’intérêt des actions que nous conduirons collectivement au service de l’économie locale.

“Soutenir le développement des entreprises régionales vers l’industrie 4.0”

De son côté Agaetis joue également un rôle primordial en intervenant dans le développement de solutions numériques autour des IoT et de la valorisation des données de production. José Alba, responsable du digital manufacturing revient donc sur ce rôle et l’offre de valeur pour les entreprises.  

Quel est le rôle d’Agaetis dans le projet Diwii ?

Au sein du consortium, nous sommes spécialisés dans le traitement et la valorisation des données pour les projets industrie 4.0. 

Nous intervenons notamment dans le développement de solutions digitales autour des IoT, systèmes connectés, mais aussi, dans la valorisation des données de production.

Les objectifs de nos interventions :

  • Améliorer le pilotage, la fiabilité et la performance globale de la production grâce à l’exploitation des données process et procédés ;
  • Anticiper les dysfonctionnements et les pannes ;
  • Baisser les coûts de non-qualité et améliorer le ROI ;
  • Sécuriser vos accès et les informations de votre entreprise.

Quelle est l’offre de valeur proposée aux entreprises ? 

Les TPE, PME et ETI peuvent s’adresser au dispositif DIWII et ainsi bénéficier d’une plateforme rassemblant un ensemble de technologies et d’expertises permettant de répondre à des études de faisabilité, des expérimentations, de la R&D et des formations. 

Dans un même lieu, vous retrouvez des académiques, des grands groupes et des PME qui travaillent ensemble pour répondre à ces besoins.

Agaetis intervient sur plusieurs technologies dans le domaine de l’industrie 4.0 : 

“L’école des mines de Saint-Etienne veut être reconnue sur l’industrie du futur”

Pascal RAY, le directeur de l’Ecole des Mines de Saint-Etienne (EMSE), revient sur l’importance du projet pour son école mais aussi les opportunités apportées par DIWII. 

En quelques mots, que représente le projet Diwii pour l’EMSE ?

L’école des mines de Saint-Étienne est une des onze écoles du groupe Institut Mines-Télécom (IMT) et a publié en début d’année 2020 une feuille de route sur l’industrie du futur. Ainsi, l’implication de l’École dans le projet DIWII est essentielle. Elle a coporté avec l’EM Lyon, dans le cadre d’un partenariat public-privé, ce projet avec le soutien à la fois de l’IMT et de sa tutelle qui est le ministère chargé de l’industrie. Elle se positionne sur ces 3 missions : 

  • La formation initiale et continue, 
  • La recherche, 
  • Le développement économique.

Comment les espaces de démonstration mis à disposition seront utilisés pour la recherche, la formation et les prestations ? 

Les 3 missions sont complémentaires. L’objectif est toujours d’accompagner les entreprises dans leurs transformations en partant de leurs besoins propres et en personnalisant la réponse apportée. Pour cela, nous avons la chance de bénéficier des expertises croisées des différents membres du consortium et de l’apport additionnel d’un réseau de partenaires.

Il est donc primordial de mettre en place un dispositif agile et coordonné de réponse aux demandes, tout en favorisant les échanges, les partages d’expérience et les mises en synergie. 

C’est le rôle de l’équipe opérationnelle d’animer cette organisation et il faudra bien sûr gérer un planning d’utilisation des différents espaces. Lorsque nous aurons à faire des arbitrages par rapport aux sollicitations, alors nous aurons réussi ce pour quoi DIWII a été créé.

Quels sont les objectifs que poursuit l’EMSE dans ce consortium ? 

L’école des mines de Saint-Etienne veut être reconnue sur l’industrie du futur tant sur le plan national qu’international en affichant l’ambition de devenir une technological University. Il est important pour l’Ecole de mieux former ses élèves à ces transitions technologiques, numériques, managériales, environnementales et sociétales et d’accompagner les entreprises  dans cette démarche.

“La mise en œuvre de système uptodate est aussi une réelle opportunité de développement scientifique”

Emmanuel Duc, professeur à SIGMA Clermont-Ferrand  insiste quant à lui sur les intérêts du projet DIWII dans le développement de nouveaux partenariats, la valorisation des compétences mais aussi la stratégie du futur Institut National Polytechnique (INP). 

En quelques mots, quels sont les apports du projet Diwii dans la stratégie du futur INP ?

DIWII s’inscrit dans une stratégie de valorisation régionale du futur INP sur le thème de l’industrie, et notamment des mutations industrielles. Ce projet permet, ainsi, à l’INP de valoriser les compétences de ses enseignants chercheurs vers le monde industriel.

Quel est l’intérêt pour SIGMA d’être présent dans ce projet ? 

L’intérêt est de développer de nouveaux partenariats sur cette thématique, qui lui permettront d’enrichir ses thématiques de recherche. La mise en œuvre de système uptodate est aussi une réelle opportunité de développement scientifique.

Quels sont les objectifs pour SIGMA ? 

DIWII est une plateforme qui appuiera le développement d’une nouvelle activité de recherche cohérente avec les thématiques actuelles de ses laboratoires.

Par la suite, le projet permettra de valoriser les compétences acquises en les diffusant auprès de nos partenaires industriels.

Conclusion

Le projet DIWII est porté par de nombreux acteurs ayant tous à cœur de faire briller l’industrie du futur régionale en soutenant les entreprises. Grâce au campus régional et à l’usine présente sur site, il sera possible de tester la numérisation de processus de production avant de mettre en œuvre leur transformation numérique, industrielle et énergétique. 

Lieu de rencontres et d’échanges, le campus a sans aucun doute un bel avenir et de beaux projets à venir ! 

Les runtimes OCI

Dans le premier article de cette série, nous avions présenté rapidement les runtimes OCI, ces outils qui permettent de transformer des images OCI en instances de conteneurs en marche. Nous allons ici faire un tour d’horizon des différentes catégories et implémentations de runtimes OCI.

Nous allons commencer par les native runtimes, se sont les runtimes les plus courants, ils utilisent directement les fonctionnalités du kernel de la machine hôte.

Suivrons les sandbox runtimes, des runtimes qui isolent un peu plus les conteneurs de la machine hôte en limitant les interactions entre le kernel et les conteneurs.

Et enfin nous nous intéresserons a Firecracker, qui est un VMM (Virtual Machine Monitor) dédié aux micro-VMs et conçu pour le serverless. C’est un outil complémentaire aux runtimes qui permet d’améliorer l’isolation des conteneurs.

Native runtimes

Les natives runtimes sont de loin les plus utilisés, se sont les runtimes par défaut de Docker, Podman, Containerd et CRI-O. Ils utilisent les fonctionnalités du kernel pour isoler le conteneur de la machine hôte. Le plus commun étant runc, et crun le challenger.

runc est le runtime de référence de l’OCI. Donné par Docker à l’OCI, il est écrit en Go. C’est le runtime par défaut de Docker, CRI-O et Containerd.

Ensuite viens crun, un runtime en C développé par Red Hat. Il est supposé plus performant que runc et est le runtime par défaut de Podman. Même si crun a supporté cgroups v2 avant runc, ce dernier a rattrapé son retard depuis.

Nous pouvons aussi mentionner ici LXC, qui utilise les fonctionnalités du kernel comme runc et crun, et permet de lancer des conteneur OCI. Mais à la différence des deux autres, LXC est conçu pour les conteneurs systèmes (par opposition aux conteneurs applicatifs), qui ne sont pas entièrement dédiés à une application mais qui tente de reproduire le comportement d’une VM classique.

Ces runtimes ont l’inconvénient de dépendre des fonctionnalités d’isolation du kernel, et ces mécanismes ne sont pas infaillibles, c’est pourquoi d’autres runtimes de natures différentes ont vu le jour pour tenter d’isoler un petit peu plus les conteneurs de la machine hôte et d’eux-mêmes.

Sandbox runtimes

Les sandbox runtimes limitent les interactions entre le conteneur et le kernel pour réduire au maximum la surface d’attaque, permettant ainsi une plus grande isolation. Dans cette catégorie nous allons voir gVisorNabla containers et Kata containers. Chacun utilisent une méthode différente pour y arriver;
gVisor implémente son propre kernel, Sentry, et son composant pour les interactions avec le système de fichiers, Gofer.

Source : gVisor

Tous les appels systèmes sont interceptés par gVisor et envoyés à Sentry, qui lui-même n’utilise que très peu d’appels au kernel. Il n’est pas non plus possible pour le conteneur de faire directement des appels systèmes. Sentry est écrit en Go pour limiter les bugs que peut contenir un kernel en C (cf. la doc de gVisor). Sentry n’implémente pas tous les appels systèmes d’un kernel classique (plus de détails ici).

Gofer quant à lui est chargé de faire le proxy pour les appels au système de fichiers, le conteneur n’a pas d’accès direct au système de fichiers.

De son côté Nabla containers utilise la technique de l’unikernel qui consiste à packager l’application avec une bibliothèque d’OS qui remplace un OS normal pour aboutir à une image de machine virtuelle minimale et dédiée à l’application.

Nabla n’utilise pas un VMM (Virtual Machine Monitor) classique (e.g. QEMU) mais un VMM spécifique, Nabla Tender, qui limite beaucoup plus les appels systèmes.

Nabla est une initiative d’IBM.

Source : Nabla container

Nabla containers n’utilisent que 7 appels systèmes sur les 300+ qui existent et limite ainsi la surface d’attaque. L’inconvénient est qu’il faut utiliser une image de base spécifique pour que l’image OCI soit compatible avec Nabla.

Nous pouvons également citer OSv dans cette catégorie, qui, comme Nabla containers, utilise le principe de l’unikernel mais sans apporter son propre VMM. Nous ne nous étendons pas plus que ça sur ce projet puisqu’il n’est que très peu maintenu de nos jours.

Kata containers est né de la fusion du projet Clear Containers d’Intel et de RunV d’Hyper.sh. Le projet est hébergé par l’Open Infrastructure Foundation (anciennement OpenStack Foundation).

Il lance les conteneurs dans une micro-VM dédiée, optimisée pour démarrer vite et conçue pour cet usage. Un composant sur la machine hôte permet de faire le proxy et d’envoyer les instructions à l’agent Kata via l’hyperviseur.

Source : Kata containers

Les micro-VMs sont des VMs avec un minimum de fonctionnalités, seulement le strict nécessaire pour faire fonctionner des conteneurs.

Kata containers supporte un petit panel d’hyperviseur : QEMU, NEMU (une version allégée de QEMU by Intel), cloud hypervisor (utilise KVM), Firecracker (quelques limitations tout de même) et ACRN.

Cette virtualisation induit nécessairement une perte de performance, mais qui reste plus intéressante que d’utiliser une VM classique et plus sécurisée qu’un runtime classique.

Ces sandbox runtimes permettent d’isoler les conteneurs, mais au prix de performances dégradées, et parfois plus : 

  • gVisor n’est pas compatible avec toutes les applications, notamment celles qui nécessitent un accès direct aux système de fichier, et il impactent aussi les performances.
  • Nabla container induit également une baisse de performance et plus important encore, il n’est pas tout à fait fini et ne semble plus très maintenu.
  • OSv n’est pratiquement plus maintenu.

En plus de ces sandbox runtimes, il existe d’autres technologies permettant d’isoler les conteneurs, et Firecracker est l’une d’elle.

Bonus : Firecracker

Firecracker est une initiative d’Amazon, c’est la technologie utilisée chez eux pour AWS Lambda et AWS Fargate. C’est un VMM (Virtual Machine Monitor) et non un runtime. Il utilise KVM, c’est une alternative à QEMU dédiée aux micro-VMs et conçu pour supporter le serverless (démarrage ultra-rapide, forte isolation entre instances…).
Firecracker a un overhead minimal et permet de faire tourner un grand nombre de micro-VMs sur la même machine hôte. Il utilise KVM pour faire fonctionner ces micro-VMs.

Source : Firecracker

En tant que tel, Firecracker n’a pas grand chose à faire dans un article sur les runtimes OCI, mais combiné à d’autres technologies, il permet de bénéficier des technologies de virtualisation pour l’isolation tout en gardant de très bonnes performances. Il est donc complémentaire d’un sandbox runtime.

Comme nous l’avons vu précédemment, Firecracker est compatible (sous conditions) avec Kata containers en plus de pouvoir être utilisé avec Containerd.

Conclusion

Les runtimes natifs utilisant les technologies fournis par le kernel comme runC et Crun peuvent ne pas être suffisant, dans certaines conditions, pour assurer une isolation suffisante des conteneurs.

Dans ce cas d’autres technologies peuvent être utilisées comme les sandbox runtimes, les plus matures étant gVisor et Kata containers. Ils permettent une meilleure isolation des conteneurs au prix d’une performance moindre et d’autres inconvénients selon la solution choisie.

En plus de ces sandbox runtimes, Firecracker permet lui aussi de mieux isoler les conteneurs tout en minimisant l’overhead. Il peut être combiné avec containerd ou Kata containers.

Dans la majorité des cas, les runtimes natifs représentent la solution la plus simple et efficace.

Un plan de relance d’un milliard d’euros et trois licornes pour la cybersécurité française

En forte augmentation depuis la crise de la Covid-19, le nombre de cyberattaques sur le territoire français a considérablement augmenté par rapport à l’année dernière. Favorisées par le télétravail, les entreprises deviennent des cibles faciles. Comme l’électricité, les attaques se produisent là où il y a le moins de résistance. Les SI des hôpitaux sont aussi fortement visées

C’est dans ce contexte anxiogène que le gouvernement a annoncé courant février la mise en place d’un plan à 1 milliard d’euros d’ici à 2025 pour renforcer le niveau de cybersécurité du territoire français. 

Financé par le programme France Relance et le programme d’Investissement d’Avenir, le Gouvernement mobilise 1 milliard d’euros, dont 720 millions de financements publics. Ce plan a pour objectif de permettre à la filière cybersécurité française d’accélérer et de multiplier par trois le chiffre d’affaires de la filière et passant ainsi de 7,3 milliards à 25 milliards d’euros. Autre mission : doubler les emplois de la filière (de 37 000 à 75 000).

Cédric Lamouche, expert en cybersécurité chez Agaetis répond dans cette interview à toutes les questions que vous pouvez vous poser autour de ce plan de relance annoncé par le gouvernement. Il met en lumière les points stratégiques du chantier de la cybersécurité en France et fait un état des lieux de la situation actuelle. 

Pour commencer, le gouvernement a annoncé ce 18 février vouloir doubler les effectifs de la filière cybersécurité d’ici 2025, en passant de 37 000 à 75 000 emplois, selon vous ce plan est-il réalisable en 4 ans et où se trouve l’enjeu de cette annonce ?

Le constat du manque de mains en cybersécurité ne fait qu’empirer d’année en années, la digitalisation des entreprises et l’exposition de leurs systèmes informatiques font qu’aujourd’hui il est difficile de pouvoir couvrir correctement les risques en cybersécurité. Il est indispensable d’accélérer la formation et la qualification de nouveaux renforts pour rapidement combler les besoins actuels. Il faut se donner les moyens d’avoir cette bulle d’air pour être proactif aux cybermenaces et sortir du mode pompier trop souvent rencontré ces dernières semaines sur tous secteurs de métiers confondus. C’est pour cela que nous avons fait le choix d’étoffer notre offre d’un service de formation à distance sous forme de réalisations de scénarios réels d’attaque avec un accès sur une plateforme SaaS. Cette offre de formation permet d’acquérir ou de monter en compétences rapidement sur des solutions technologiques de cybersécurité et des méthodologies d’attaque/défense.

La transition numérique a-t-elle été trop rapide pour maîtriser les risques de cyber sécurité ?   

Incontestablement oui, l’accélération des derniers mois sur l’ouverture des systèmes d’information a créer des brèches au niveau de la gestion de la sécurité. Pour répondre à des besoins de continuité d’activités des entreprises ont dû ouvrir rapidement et sans analyse des risques leurs SI. On estime que certains secteurs ont gagné 5 ans en maturité de digitalisation, si on regarde le temps que prennent habituellement l’évaluation des risques et l’écriture d’un plan de gestion on voit que la sécurité ne peut plus suivre à ce rythme effréné. Il devient judicieux d’aller vers des approches de micro segmentations et de moindre privilèges pour arriver à maîtriser ses nouvelles expositions.

Avec son plan de relance d’un milliard d’euros, dont 720 millions de financements publics, le gouvernement veut faire émerger des champions de la cybersécurité et trois licornes françaises. Vous pouvez nous en dire plus ? Quels sont leurs objectifs et y en a t-il déjà sur le territoire français ?

La France a toujours été pionnière dans les nouvelles technologies et encore plus en cybersécurité. Nous n’avons rien à envier à nos voisins européens et partenaires outre atlantique mais il est important de garder cette volonté nationale d’avoir nos propres solutions nationales en développant et intégrant notre R&D reconnue mondialement.  Il y a encore de la place sur des sujets d’automatisation, de veille et d’analyse, mais il est indispensable de piloter ces projets afin de ne pas se retrouver avec des doublons ou fork de solutions. L’état à tout à jouer et son rôle sur les prochaines années sera primordial notamment à veiller à ce que cette R&D et ces solutions restent sur le sol Français !

Bruno Le Maire, Ministre de l’Économie, des Finances et de la Relance, a déclaré que la cybersécurité était un “enjeu majeur du XXIe siècle” et qu’elle était “essentielle à la souveraineté des États, à la pérennité du développement des entreprises et à la sécurité des citoyens”. Comment se situe la France par rapport aux autres puissances mondiales dans la sécurisation de ses SI ? Sommes-nous en retard ou plutôt en avance ? 

Nous avons une bonne sécurisation globale sur l’ensemble du CAC 40 qui sont impactés et régis par des réglementations de plus en plus drastiques sur la sécurisation des données, on retrouve par exemple le RGPD, la LPM, NIS etc … Mais il reste encore beaucoup à faire sur le segment de marché intermédiaire où peu de sociétés sont soumises à des réglementations à part le RGPD qui concerne tout le monde. On le voit aujourd’hui des secteurs sont des cibles privilégiées comme la santé et les administrations publiques, on ne peut pas dire que ces structures n’ont pas investi dans des moyens de protections mais force est de constater qu’aujourd’hui elles arrivent à leurs limites. Il faut pouvoir leur proposer des solutions de cyber défense adaptées aux niveaux des fonctionnalités mais surtout au niveau coût d’acquisition. De nouveaux business  models doivent être inventés pour rendre accessible ces solutions avec des tickets d’entrées acceptables.  La mutualisation peut être une porte de sortie vers le haut pour faire face rapidement à ces cybermenaces de plus en plus sophistiquées.

Un des axes d’action avec ce plan de relance est de diffuser une véritable culture de la cybersécurité dans les entreprises, quelles vont être les missions principales pour que cette culture soit adoptée et à quel niveau est-elle déjà présente en France ?

En France nous avons déjà un très bon travail de sensibilisation de l’ANSSI qui sort régulièrement des guides sur la sécurisation des SI, en parallèle l’état a mis en œuvre la plateforme cybermalveaillance.gouv.fr qui permet de donner des conseils aux entreprises mais surtout de les prendre en charge dès lors des premiers signaux d’attaque. Il ne faut surtout pas relâcher les efforts et les messages doivent être relayés régionalement, départementalement et localement. Il doit y avoir beaucoup plus d’interactions entre les sociétés de service en cyber sécurité, les partenaires locaux et les entreprises car les enjeux sont communs autour d’une volonté de croissance et de pérennité.

Enfin un des derniers axes d’action est de stimuler la recherche française en cyber et l’innovation industrielle avec dans l’idéal une hausse de 20% des brevets, est-ce réalisable en 4 ans et quels sont les sujets les plus importants à traiter selon vous ?

Oui, c’est tout à fait raisonnable, nous avons une très bonne R&D comme je vous le disais plus haut mais encore faut-il savoir la valoriser et lui donner les moyens de passer à l’échelle. Trop de projets restent dans les tiroirs des laboratoires soit par manque de financement ou de méthodologie pour aborder le marché. Entre avoir une idée et la valoriser commercialement ce n’est pas si simple que ça si ces laboratoires ne sont pas accompagnés le taux de résultat sur le delivery et l’usage restera très faible. Je suis tout à fait d’accord sur le besoin de produire des brevets mais il faut absolument une dynamique de valorisation de ces brevets et surtout de veiller qu’ils permettent de donner de la croissance aux entreprises françaises.

Et Agaetis dans tout ça, où vous situez-vous et où en êtes-vous ? 

Nous avons pris le virage de la cybersécurité car de plus en plus de projets que nous abordons requièrent des niveaux de sécurisations importants. Il est très rare aujourd’hui de trouver des projets clients sans une volonté de sécurisation ce qui est plutôt rassurant pour nous consommateurs et usagers de ces projets de digitalisation. Notre expertises et nos retours d’expériences nous permettent d’être dans l’anticipation sur des sujets brûlants comme la cybersécurité c’est pour cela que nous avons produits des offres baptisées :

Plan Marshall Cyber pour donner un accès avec un budget limité à une sécurisation du SI.

E-training Cyber pour se former rapidement sur les périmètres vastes et techniques de la cybersécurité.

Couverture cyber 360° en intégrant une solution Zéro trust et de Soc as a service.

Comment organiser la résilience de son SI ?

Victime d’un incendie dans la nuit du 9 mars, un datacenter d’OVH a subi de lourdes pertes. Ne faisant heureusement aucun blessé physique, l’accident a néanmoins provoqué la perte totale du datacenter SBG2 et une partie de SBG1 (quatre salles serveurs). 

Grâce à l’intervention des pompiers, les deux autres datacenters, SBG3 et 4 ont pu être sauvés, a affirmé Octave Klaba, PDG d’OVHCloud sur Twitter. Ce dernier a d’ailleurs récemment publié une vidéo pour faire un état des lieux de la situation

Malgré tout, pour maîtriser l’incendie, une coupure de courant totale n’a pas pu être évitée. Ainsi ce sont 3,6 millions de sites web, représentant 464 000 noms de domaines distincts qui se sont retrouvés hors ligne. 

Organiser la résilience de son système d’information est primordial dès lors que l’on construit un projet. Pour être sûr de ne pas perdre ses données et de voir son site fonctionner malgré certains aléas, l’architecture et le choix de disponibilités des machines doit être réfléchi en amont. Comment faire pour rendre son SI plus résilient ? C’est la question à laquelle nous allons essayer de répondre ! Face à cet événement, Célyne Courmont, a essayé de comprendre l’impact depuis sa fenêtre de néophyte. En se basant sur des expériences propres à Agaetis et sur l’exemple de l’incendie d’OVH, Pierre Pironin nous éclaire sur le fonctionnement des datacenter et sur l’importance de son architecture ainsi que des Disaster Recovery Plan. Cédric Lamouche nous explique également la considération qu’il faut apporter à la lecture et la compréhension des contrats.  

Quel est le lien entre la disponibilité de services et les datacenters physiques ?

Prenons l’exemple de Kubernetes, qui est la plateforme permettant d’automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d’application sur des clusters de serveurs, que nous utilisons le plus chez nos clients

Kubernetes est hébergé sur des machines virtuelles (VM) sur des serveurs chez un cloud provider (prenons ici l’exemple d’Azure mais le cas serait tout à fait similaire sur OVH). Un cluster Kubernetes est composé de plusieurs VM et donc de plusieurs serveurs. 

Une des façons de provisionner du Kubernetes dans Azure est d’adopter un modèle Infrastructure as a Service (IaaS), c’est à dire qu’Azure fournit des briques d’infrastructures comme des VM, du réseau, du stockage… 

Toutes ces briques d’infrastructure ont un Service Level Agreement (SLA) ou Service Level Objectives (SLO) qui correspond au temps de disponibilité ou d’indisponibilité des briques de l’infrastructure garantie par Azure

Plus le SLA est haut, plus la qualité de service est bonne car cela signifie que le temps de service sera le plus élevé possible (pas d’interruption ou le moins possible). Ainsi pour créer des architectures résilientes, on vise un haut niveau de SLA sur les briques d’infrastructure.

Les salles serveurs des datacenters sont remplis d’armoires contenant des racks dans lesquels se trouvent des serveurs physiques qui font fonctionner les machines virtuelles (VM) La VM fonctionne donc dans une armoire de serveur, se trouvant dans un bâtiment. Si ce bâtiment brûle (ou qu’un autre type d’incident se produit) et qu’il n’y avait qu’une machine virtuelle pour héberger la plateforme, toutes les données sont perdues et la SLA descend logiquement à 0, le temps de disponibilité des machines étant nul. 

Pour se prémunir de ce genre d’incidents, les datacenters tels que Strasbourg pour OVH ou encore Amsterdam pour Azure, vont être organisés en zones (SBG1-4 pour OVH par exemple). Nous retrouvons sur un site plusieurs édifices distincts, ayant leur propre alimentation électrique, ventilation, coupe feu… Ces structures sont normalement assez isolées les unes des autres. Ainsi si un problème survient dans un bâtiment, les autres peuvent continuer de fonctionner (hors cas exceptionnels comme l’incendie d’OVH).

Bien définir son architecture : exemple de Kubernetes

Lorsque l’on travaille sur du Kubernetes, on peut par exemple investir dans trois VM au lieu d’une. Kubernetes va lui-même se charger de répartir les tâches de travail sur les 3 machines virtuelles et chacune de ces machines sera placée dans des bâtiments différents. Ainsi, si un problème survient dans un des datacenter, une VM peut se retrouver inexploitable à un moment donné mais les deux autres prendront le relais. Kubernetes y dispatchera toute la charge de travail et continuera de faire fonctionner le tout. Ce sont les zones d’un datacenter. 

Pour Pierre Pironin, spécialiste cloud chez Agaetis, le plus gros problème survenu à OVH, c’est que tous les projets étant hébergés dans le datacenter qui a brûlé et n’ayant pas été répartis sur plusieurs zones ont perdu toutes leurs données. La seule solution est alors d’aller chercher des backups sauvegardés ailleurs (dans un autre cloud ou un autre datacenter par exemple) pour les restaurer

L’intérêt de ces différentes zones est également de pouvoir appréhender des bugs. Par exemple, lorsque Azure fait des modifications de son infrastructure, ils s’assurent de ne pas le faire sur toutes les zones en même temps. Ainsi, si ils introduisent un bug dans une zone et que celui-ci en détériore les fonctionnalités, les autres zones vont pouvoir continuer à fonctionner. C’est à la fois une sécurité physique et logique par rapport aux actions de maintenance menées par les équipes d’infrastructure. 

Kubernetes peut absorber la perte de chacune des zones en dispatchant la workload sur les autres VM. Cela permet de s’assurer que les applications hébergées sur le cluster Kubernetes n’ont pas été impactées par la perte d’une zone. 

Le cas des applications hypercritiques

Des incidents comme des incendies, des inondations ou des séismes peuvent faire tomber plusieurs bâtiments et même la totalité d’un site. 

Dans certains cas et dans certaines entreprises on se préserve de ce genre d’événements pour les applications hypercritiques. En plus d’être hébergées sur un cluster Kubernetes dans un datacenter comme les autres, elles sont également hébergées sur un autre cluster Kubernetes identique ou quasi identique dans un autre datacenter, c’est le niveau de service maximum mis en place dans le cadre d’un Disaster Recovery Plan (DRP). Cela permet de prévenir une perte totale des VM et ainsi assurer un relai pour les applications hypercritiques. 

La lecture et la compréhension des contrats

Pour Cédric Lamouche, expert en cybersécurité chez Agaetis, le contrat, souvent lu et signé dans la précipitation ou en complète confiance avec le prestataire est un acte d’engagement fort bipartie. Il est partie prenante de la gestion des risques dans l’entreprise ce qui impose d’en avoir une lecture précise et attentive, il doit surtout être en adéquation avec le contrat de service que vous attendez du prestataire mais aussi des engagements de sécurité et de productions garanties à votre entreprise. Oui, cela peut paraître normal, banal, acté que, par exemple, vos données soient sécurisées sur l’hébergement de votre prestataire mais dans quelles conditions ? Est-ce compatible avec votre activité ? Les piliers fondamentaux de la sécurité qui sont disponibilité, intégrité et confidentialité doivent être, là aussi, évalués. Souvent par questions de coûts finaux on peut faire l’impasse sur des options ou fonctions qui, si elles ne sont pas évaluées, peuvent avoir des conséquences désastreuses pour le business de l’entreprise.

Aujourd’hui suite à la perte de ce datacenter chez OVH combien de sociétés sont laissées sur le carreaux ? Combien de sociétés se retrouvent sans sauvegarde ? Combien d’entre elles n’ont plus accès à leur service email ?

Il n’est pas trop tard pour reprendre vos contrats, comprendre ce qui est mentionné et voir si les engagements de vos prestataires sont en adéquation avec vos exigences de sécurité et votre continuité d’activité. 

Conclusion

Si il y a une chose à retenir de cet incendie c’est la suivante : au moment du déploiement il faut être rigoureux et bien choisir les disponibilités des machines. Selon les besoins et les projets il faut qu’un DRP soit monté en amont afin de se prémunir de ce type d’ennuis. Adopter une approche résiliente dès le départ c’est s’assurer que son SI continue de fonctionner et de vivre même en cas d’incidents graves. 

Si vous avez des questions ou simplement envie d’échanger sur le sujet n’hésitez pas à nous contacter ! 

Helping the customer to understand what he did a long time ago…

In a galaxy far, far away…

EV-9D9: “How many languages do you speak?

C-3PO: “I am fluent in over six million forms of communication and can readily…”

EV-9D9: “Splendid. We have been without an interpreter since our master got angry with our last protocol droid and disintegrated him.

C-3PO: “Disintegrated?

EV-9D9: “Yes, Disintegrated …. Can you read and write a dialect of SQL, MySQL and generate AST to translate to another database language ? We have 70.000 SQL statements that we don’t really understand …

C-3PO: “Of course I can ! I have a built-in ANTLR4 device that can do that!

EV-9D9: “Perfect! You’re in then! Follow me…

When I started to work for one of my customers, they asked me to change their monolithic platform to a full distributed one with HA. If it was so monolithic and full of SPoF’s, it was not because of a real lack of skills or vision but it was more a history made by events, people and… turn over. The lines of code I found and the design of the platform were telling me a real story implying machines, code and human beings spread over more than 4 years of hotfixes, maintenance and development.

Who is my secret customer ?

Of course, I can’t say any name of company (or I will have to hire Boba Fett …) but I need to describe the flow of data which is the key to designing a new architecture.

First things first, Auto !

The first thing to know is : we’re gonna listen to clusters of machines. These are industrial machines producing a huge amount of data every second. All these expensive bunches of steel and iron are grouped by site and will send all that data through an ftp connection (yes, you read it correctly…) using a 4G or landline connection. Sometimes those sites are really in the middle of nowhere (it sounds like Tatooine, I know…).

Second things… Second !

These data going through the FTP pipe are then processed and inserted in a MySQL database. All this data will provide dashboards and visual tools to monitor customer sites.

What’s up doc ?

My customer needed to build a brand new platform that will be able to scale-out, to be easy to maintain and, of course, that will be iso-functional to the existing one.

That’s when the tricky part comes in : all the computation logic for aggregations are stored in the SQL database as SQL strings (e.g. : “AVG(FIELD1)”) in a table. When the computation needs to be done, all requests are concatenated in one to be executed later.

The caveat is : it’s really hard to maintain a system where you have strings that contain something written in a language (In that case SQL) that you manipulate like simple pieces you put together. Without knowing if the concatenated query is valid or makes sense, running it is at your own risk. If you have a few hundreds of it, then you can have human eyes to check it … but when it’s 70.000 request blocks then… you don’t want to hear about “testing it all by hand » !

Goal of my mission (you said impossible ?)

The main goal of my mission was to build the new platform and migrate the current SQL logic to something else. The chosen database to store all messages from the different sites was Elasticsearch. The problem was : the SQL computation was not translatable to an Elasticsearch query or aggregation.

So we decided to explore all these SQL requests to try to simplify and maybe afterwards to translate to Elasticsearch “jsonish” queries (with painless script of course) or to run a dockerized SQL engine for some of them in a streaming way. I mean whenever we receive a message from FTP it will trigger computation using a SQL engine on a limited time window. These aggregations will then consolidate Elasticsearch database. Helping the customer to understand these queries would maybe bring questions or a different point of view of the running platform.

How to evaluate complexity of SQL queries stored as strings ?

The answer is : use a lexer and a parser that understand SQL grammar. This, maybe, looks tricky but if you use ANTLR4 … it’s not !

My idea was to use Zeppelin and therefore Spark to load and work on these bunch of queries. The advantage of doing this is that you can try and fail, changing your code quickly in the Zeppelin notebook and find exactly what you were looking for.

So the first thing to do was to package a lexer/parser in order to add it as a spark dependency and use it directly from the notebook.

Find the grammar for your parser

To find the right grammar for my parser, I checked this repository. It’s a compilation of a lot of grammars organized by folder. I found the droids ones I was looking for (even if a weird old bearded man told me : “these aren’t the ones you’re looking for”). There were 2 files : one for the lexer (MySqlLexer.g4 : tokens allowed) and one for the parser (MySqlParser.g4: rules). These are the 2 files I downloaded to prepare my lexer/parser project.

Compile and package the SQL lexer/parser

To compile and package the lexer/parser, I wrote a small project using maven and its really useful plugin antlr4-maven-plugin. First I wrote a pom.xml to describe the project (groupId, artifactId, …) and some version stuff. Here is the pom.xml (I removed some verbose xml to make it more readable) :

<project ...>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.agaetis.antlr4.mysql</groupId>
    <artifactId>parslex</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>MySQL Antlr 4 Lexer/Parser</name>
    <properties>
        …
        <antlr4.visitor>true</antlr4.visitor>
        <antlr4.listener>true</antlr4.listener>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.antlr</groupId>
            <artifactId>antlr4-runtime</artifactId>
            <version>4.7.2</version>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.antlr</groupId>
                <artifactId>antlr4-maven-plugin</artifactId>
                <version>4.7.2</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>antlr4</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.6.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

pom.xml

Then in the root folder of the project (next to the pom.xml) I created one folder to put all the grammar files : src/main/antlr4/com/agaetis/antlr4/mysql. Here is the structure of the project :

File structure

When you have your project setup, the next step is to package the jar. For that purpose, of course, we use the antlr4 maven plugin like this :

mvn clean install

After that you should have in your local maven repository the jar that you will use with Zeppelin/Spark.

~/.m2/repository/com/agaetis/antlr4/mysql/parslex/0.0.1-SNAPSHOT/parslex-0.0.1-SNAPSHOT.jar

Add the parser package as a dependency in the Zeppelin Spark Interpreter

When you have your parser packaged and ready to be used, you need to tell Zeppelin and Spark to make it available from your notebook. In the interpreter section you just have to search for spark interpreter, edit it and add in the end of the page the dependency to the package located in your maven repository.

All requests that will be parsed are in a MySQL database, therefore I added a dependency to the connector to access a MySQL database and because we’re going to use ANTLR4, obviously, I added as well the ANTLR4 runtime dependency.

Load queries from the database

Here is the snippet to create a dataframe from a MySQL table :

val options = Map(    "url"       -> dbUrl,
    "dbtable"   -> tableName,
    "user"      -> userName,
    "password"  -> userPassword,
    "driver"    -> "com.mysql.jdbc.Driver"
)
val queries = spark.read.format("jdbc").options(options).load
queries.cache()

queries.count

jdbc-spark-connect.scala

That means, you’ll be able to use Spark dataframe operators to manipulate (filter, map …) your queries. How to compute the complexity of a SQL statement ?

The most intuitive way to compute the complexity of a SQL query (the one that came in my mind first), was, IMHO, the computation of the complexity of the AST (Abstract Syntax Tree) that represents a given SQL query (that’s why I used a library like ANTLR).

Let’s take an example : here is a query that is just a SELECT statement without any FROM part or WHERE statement.

SELECT IF(AVG(age) > 10, (AVG(age) * 20), 0)

ANTLR4 will compute an AST for that query that looks like this :

Example of an AST (simplified) for a SQL query

In that case, the purpose of the query is : if the average of the field age is greater than 10, then the value returned is the average of the field age multiplied by 20, otherwise the result is 0. This query is not a complicated one but it shows what the AST looks like.

We can see that we have five layers (I don’t count the first one AST in the picture). My first idea was to compute the number of elements for each layer times the layer index (first level has index equals to 1) and then to multiply them. In practice, the number returned in that case is too high. So I computed the natural logarithm of each number of nodes per layer times the level of the layer (plus 1 because it’s a logarithm) and then multiplied them to apply finally a last natural logarithm.

So in this example the complexity would be :

ln((ln(level*N1)+1)*(ln(level*N2)+1)*(ln(level*N3)+1)*(ln(level*N4)+1)*(ln(level*N5)+1))

which equals to :

ln((ln(1*2)+1)*(ln(2*4)+1)*(ln(3*5)+1)*(ln(4*4)+1)*(ln(5*2)+1))

That gives 5.48. When we use this query in the function implemented in the notebook we don’t have the same result because I simplified the abstract syntax tree to illustrate the complexity factor computation. ANTLR4 generates a more complex tree from this same query and therefore, we get a higher complexity factor when it is executed in the notebook.

Here is the code to compute the complexity of a query :

import com.agaetis.antlr4.mysql.MySqlParserBaseListener
import com.agaetis.antlr4.mysql.MySql Lexer
import com.agaetis.antlr4.mysql.MySqlParser
import org.antlr.v4.runtime.ParserRuleContext
import org.antlr.v4.runtime.CharStream
import org.antlr.v4.runtime.CharStreams
import org.antlr.v4.runtime.CommonTokenStream
import org.antlr.v4.runtime.tree.ParseTree
import org.antlr.v4.runtime.tree.ParseTreeWalker
import scala.collection.mutable.Map

class MyListener extends MySqlParserBaseListener {
    val nodeCountPerLevel = LinkedHashMap[Int, Int]();
    override def enterEveryRule(ctx:ParserRuleContext) {
        nodeCountPerLevel(ctx.depth()) = nodeCountPerLevel.getOrElse(ctx.depth(),0) + 1
    }
}

class MyErrorListener extends BaseErrorListener {
    @throws(classOf[ParseCancellationException])
    override def syntaxError( recognizer: Recognizer[_, _],
                              offendingSymbol:Object, line:Int ,
                              charPositionInLine:Int ,
                              msg:String ,
                              e:RecognitionException) = {
                                  println(s"ERROR $msg")
                                  throw new ParseCancellationException(msg);
                              }
}

def evalComplexity(input:String, exprType:String) : Double = {
    if(input == null || input.isEmpty)
        0
    else {
        try {
            val inputCharStream = CharStreams.fromString(input)
            val sqlLexer:MySqlLexer = new MySqlLexer(inputCharStream)
            val tokenStream = new CommonTokenStream(sqlLexer)
            val parser = new MySqlParser(tokenStream)
            parser.removeErrorListeners();
            parser.addErrorListener(new MyErrorListener());
            val tree:ParseTree = exprType match {
                case "SELECT" => parser.selectStatement()
                case "EXPR" => parser.expression()
                case _ => parser.root()
            }
            val walker = new ParseTreeWalker()
            val listener = new MyListener()
            walker.walk(listener, tree)
            val nodeCountPerLevel = listener.nodeCountPerLevel
            println(nodeCountPerLevel.size)
            val score = nodeCountPerLevel.map {
                case (k,v) => { 
                    Math.log(k * v) + 1.0
                }
            }.reduce( (a,b) => a * b )
            Math.log(score)
        } catch {
            case e:ParseCancellationException => -1.0
        }
    }
}

evcplx.scala

Here is an example of using this function :

Using dataframe (where the queries are) and udf’s (user defined functions), you can add a complexity column to your dataframe like this :

def evalComplexityUdf = udf((input:String) => {
    evalComplexity(input, "EXPR")
})

val allQueriesWithComplexity = allQueries.withColumn("valCplx", evalComplexityUdf($"query"))

df-evcplx.scala

Then you can display and see the complexity of any query in the dataset :

And so what?

Then we were able to identify complex queries, to analyze why it was so complex and to check if it was still in use in the system. There was also an advantage in using this method : we found few invalid statements in the MySQL database (missing parenthesis, invalid variable names …). These queries have since been corrected or removed if it was not used anymore.

The customer was able to understand a bit more what was in the database, and it was a good start to rethink the way these queries should be kept or mapped to Elasticsearch.

Conclusion

When you have a SQL-based system that contains SQL queries which will be concatenated or manipulated as strings then you can assume that it’s not the best practice you can find. Indeed, it’s a trick that hides a deep misconception problem of your platform. In that case you can either run away and say you can’t do anything for them or you can pluck up the courage to give sense to customer’s data and make them understand that there is always a better way : rethink the data modeling and use a database that fits better the use case.

Space Odyssey – Warner Bros. Entertainment Inc.

Even if the project looks like a space odyssey to the customer (like fighting against an “already in place” platform to change the way it thinks), there’s always a way or a workaround to ignite a seismic shift.

Les builders d’images OCI, 6 alternatives à Docker

Dans les deux premiers épisodes de cette série d’articles sur les conteneurs, nous avons fait un petit tour des conteneurs applicatifs en général, puis des container engines avec Docker et Podman.

Les containers engines sont très bien pour le poste de travail : ils permettent de tout faire avec un seul outil. En revanche dans d’autre cas, mettons dans une étape d’un pipeline de CI/CD, nous ne voulons rien faire d’autre que construire une image de conteneur avant de la pousser dans un registre d’image. Et pour cet usage, de nombreux outils autre que Docker ont fait leur apparition. Nous allons donc parler des builders.
Nous commencerons par Docker, l’incontournable et son nouveau composant en charge de la construction de conteneurs : BuildKit. Nous regarderons ensuite quelques alternatives plus légères et plus appropriées dans un contexte de CI/CD : Kaniko, umoci, Buildah et img. Enfin nous jetterons un coup d’œil sur des plugins d’outils de build plus généraux avec Jib (Maven/Gradle) et Bazel.

Docker et BuildKit

Docker permet de construire des images de conteneur à l’aide de la commande docker build, et depuis la release 18.09, il est possible d’utiliser BuildKit à cet effet.

BuildKit est un outil à part entière qui peut être utilisé seul (avec le CLI buildctl et le daemon buildkitd) mais qui est également embarqué dans Docker lui-même. Pour l’activer, rien de plus simple, il suffit de lancer son build avec la variable d’environnement DOCKER_BUILDKIT=1. Ne soyez pas surpris, par défaut les logs sont un peu différents du docker build “legacy”.

BuildKit apporte quelques fonctionnalités supplémentaires :

  • La parallélisation des builds multi-stage, cet article décrit assez bien cette fonctionnalité.
  • L’intégration des Docker secrets dans l’étape de build (docs)

BuildKit peut aussi être utilisé avec les commandes docker buildx, même si ces commandes sont encore considérées comme expérimentales. Buildx permet d’utiliser toutes les fonctionnalités de BuildKit, comme la possibilité créer des instances de builders séparées pour éviter le partage d’une seule et même instance pour tous les builds.

Maintenant que nous avons vu ce que permet de faire docker, intéressons nous aux alternatives, et pour commencer, Kaniko.

Kaniko

Kaniko est un outil open source développé par Google pour construire des images à partir de Dockerfile et depuis un conteneur, sans avoir accès à un daemon Docker. Par conséquent, il permet de construire une image depuis un conteneur dans un cluster Kubernetes par exemple.

L’utilisation est plutôt simple puisque tout se passe dans le conteneur avec l’image officielle gcr.io/kaniko-project/executor et en une étape qui rassemble les étapes habituelles de pull, build et push.

Par défaut, Kaniko permet de construire une image depuis un dossier local, donc un dossier dans le conteneur ou un volume monté dans le conteneur. Mais il est aussi possible de construire une image depuis un blob storage (AWS S3, Azure Blob Storage, GCS Bucket) ou un dépôt git directement.

Il est aussi possible de configurer du cache pour accélérer les pipelines de CI/CD.

Cet outil est très facile à mettre en place dans un environnement de CI/CD comme Gitlab CI ou Github Actions.

umoci

umoci est l’implémentation de référence de l’OCI image, il est conçu pour être minimal afin de pouvoir plus facilement s’intégrer dans un système plus gros. Par conséquent, il n’est pas forcément très “user-friendly” et manque des fonctionnalités des autres builder comme le push et pull vers une registry par exemple. Il permet également de construire des images en mode rootless.

Il est mentionné ici à titre indicatif et puisqu’il s’agit de l’implémentation de référence. C’est aussi un bon moyen de comprendre les arcanes de la construction d’image sans avoir à lire le code source d’un autre builder.

Buildah

Buildah est le cousin de Podman, container engine dont nous avons parlé dans l’épisode précédent. Comme Podman, il n’a pas besoin de daemon et peut fonctionner en mode rootless. C’est un outil développé par Red Hat qui permet, entre autres, de construire des images OCI de façon classique à partir d’un manifeste Dockerfile, via la commande buildah bud.

Mais la fonctionnalité la plus intéressante est de créer une image à partir d’un filesystem. Grosso modo il permet de créer une image à partir d’un dossier. Ce qui est très pratique pour créer des image from scratch, c’est-à-dire que contrairement à la majorité des images de nos jours, on peut créer une image distroless qui ne contient que le strict minimum, donc pas forcément d’outils systèmes comme un shell ou un package manager (e.g. yum ou apt), puisque que l’on peut utiliser le package manager de la machine hôte pour installer des packages dans le dossier qui servira comme base de la future image. Voici un exemple utilisant dnf pour installer bash dans un conteneur “nu”, tiré de la documentation de buildah :

# Crée le conteneur nu, “from scratch”, avec juste quelque métadonnées

$> newcontainer=$(buildah from scratch)

# Monte le conteneur dans un dossier

$> scratchmnt=$(buildah mount $newcontainer)

# Installe bash et coreutils dans le conteneur

$> dnf install --installroot $scratchmnt --releasever 33 bash coreutils --setopt install_weak_deps=false -y

# Démonte le conteneur

$> buildah unmount $newcontainer

# Commit le conteneur pour pour créer l’image fedora-basheco

$> buildah commit $newcontainer fedora-bashecho

umoci permet de créer des images OCI de la même façon mais l’expérience utilisateur n’est pas la même puisque buildah va abstraire tout ce qu’il peut pour rendre l’expérience la plus fluide possible, quand umoci se contentera du minimum.

L’intérêt de buildah par rapport à Kaniko dans un système de CI/CD est limité pour le cas d’usage classique à partir d’un Dockerfile. En revanche, buildah est un outil clairement intéressant pour la création d’image “from scratch”.

img

img est un builder daemonless et rootless qui utilise une partie de BuildKit en interne, sans pour autant dépendre du daemon buildkitd.

Comme BuildKit, il permet d’effectuer des étapes de builds en parallèle pour les multi-stage builds. Les options du CLI img sont similaires à celles du CLI docker pour les actions de build, pull et push. Du point de vue de l’utilisateur, l’expérience est donc tout à fait similaire à celle de Docker.

img est donc un bon candidat pour remplacer facilement docker dans un système de CI/CD déjà en place afin de bénéficier du mode rootless par exemple.

Jib et Bazel

Jib et Bazel sont des cas particuliers de builders : se sont des plugins d’outils de build plus généraux. En effet, Jib est un plugin pour Maven et Gradle, quand Bazel est un outil de build plus général qui dispose de son propre plugin pour construire des images Docker et OCI.

Ces deux outils permettent de construire des images OCI et Docker rootless et daemonless. Le gros point fort étant l’intégration avec l’outil de build dont ils sont le plugin. Il est donc très facile pour un utilisateur de Maven de construire une image Docker avec Jib.

Le deuxième avantage c’est l’utilisation d’images distroless par défaut, c’est-à-dire des images qui ne contiennent que le strict minimum : pas de shell ou de package manager.

Ces deux outils sont à privilégier pour les utilisateurs de Maven et Bazel. Ils permettent de construire des images très facilement et de façon complètement intégré au processus de build habituel.

Conclusion

Dans certains contextes, comme dans un environnement de CI/CD, un outil léger et dédié à la construction d’images Docker ou OCI est plus approprié que Docker ou Podman.

Nous avons vu que Docker et BuildKit permettent quelques améliorations par rapport à la construction de conteneur par défaut de Docker, notamment la construction en parallèle de multi-stage images, mais ils nécessitent des daemons.

umoci est intéressant pour comprendre la mécanique de construction d’une image, mais est un peu trop minimaliste pour être utilisé en mode standalone.

Kaniko permet de facilement construire une image de conteneur depuis un conteneur sans privilèges et daemonless.

img permet de construire des images avec la même syntaxe que le CLI Docker et en étant aussi efficace que BuildKit sans pour autant nécessiter de daemon et sans privilèges.

Enfin Jib (Maven/Gradle) et Bazel permettent d’intégrer la construction d’image dans un outils de build plus généraliste, et ainsi obtenir une intégration tout en douceur dans un système existant.

Nous avons vu que dans la catégorie des builders, Docker n’est clairement plus hégémonique non plus. Dans le prochain article nous ferons un tour d’horizon des runtime OCI.

En attendant le prochain épisode, n’hésitez pas à aller consulter nos précédents articles sur Docker, les conteneurs et l’Open Container Initiative (OCI), les container engines : Podman, l’alternative à Docker mais aussi celui sur comment adopter une approche Kubernetes First !

Pourquoi React Native est toujours une bonne solution en 2021

On ne présente plus React Native en 2021. Bien au contraire, la plupart de ses détracteurs actuels seront plutôt de l’avis que c’est du passé, dû notamment à l’arrivée de technologies comme Flutter ou les PWA. Nous n’en sommes pas convaincus à Agaetis et nous allons vous expliquer pourquoi dans cet article. La principale raison est évidente : il n’y a pas de solution universelle qui réponde à tous les use-cases de la meilleure façon possible.

Rappel des intérêts de React Native

Avant d’entrer dans les détails, faisons un petit rappel des avantages de cette technologie par rapport à du développement natif (sous Kotlin et Swift). On distingue 3 points principaux :

  • L’avantage principal est bien évidemment le partage de code entre les deux plateformes : mêmes équipes de développement, mêmes tests et généralement moins de coûts !
  • React Native profite par ailleurs de la popularité de JavaScript : une communauté plus développée que Kotlin et Swift, donc plus de facilités pour recruter, faire monter en compétences, etc… Il profite également de la puissance de React pour créer des interfaces, après tout, SwiftUI en est inspiré ce n’est sûrement pas un hasard ! 
  • Enfin l’environnement de développement est plus “puissant” grâce au caractère interprété du JS face à ces 2 langages compilés, à travers notamment le hot reloading (donc encore des gains de productivité à la clé !).

Évidemment le tout est au prix d’une baisse de performances face à du développement natif, mais cela reste préférable à ce niveau, que des applications web hybrides ou des PWA. React Native a d’ailleurs un autre avantage face à ce type d’applications web : l’utilisation de composants natifs à l’affichage. L’utilisateur a l’impression d’utiliser une application native, en échange d’un démarrage un peu plus lent (on en reparle plus bas).

Représentation schématique du fonctionnement de cette technologie jusqu’à maintenant. A gauche le thread JS qui exécute le code de l’application. A droite en orange le thread “natif” classique (pour l’UI), vers lequel sont transpilés les composants graphiques au lancement de l’application. Le “Bridge” React Native relie le tout pour que l’ensemble fonctionne (par l’échange de messages asynchrones). Enfin on trouve “Yoga”, le moteur de calcul pour l’agencement des composants à l’écran.

Les trois facteurs déterminants pour le futur de React Native : Expo, Hermes  et “JSI”

En quelques années, Expo est passé d’un petit framework sur-couche de React Native, à un must have pour la plupart des projets. Dans le même temps, l’équipe de ce dernier travaille à la mise en place du nouveau moteur Hermès qui promet des temps de démarrage bien meilleurs (2x plus rapides !).

Expo

Expo permet à l’origine de répondre au problème principale de React Native pour les développeurs : la dépendance au code natif. En effet, l’abstraction n’est pas complète et il faut toujours y toucher un peu lorsque l’on souhaite accéder à une API hardware (principalement lorsqu’on ajoute la dépendance). Et par ailleurs seuls les développeurs sous Mac peuvent développer et vérifier que l’application fonctionne sur iOS. Ce n’est plus le cas avec Expo, ce framework a indéniablement participé à l’émancipation de React Native.

A l’heure actuelle, le framework continue de se développer et va plus loin, notamment avec un système de mises à jour automatiques sans passer par les stores, à la manière des PWA (pas besoin de gérer de la rétrocompatibilité avec le backend !).

Evidemment Expo étant encore plus récent que React Native, son utilisation ne se fait pas sans contreparties : le support du Bluetooth, par exemple, n’est pas encore disponible. Mais à noter qu’il est possible à tout moment dans la vie d’un projet sous Expo de revenir à du React Native pur.

Hermès

La première fois qu’une application React Native est démarrée, elle va compiler ses composants graphiques en composants natifs (comme vu plus haut). Cette compilation n’est évidemment pas économe en temps et cela peut se faire ressentir ! Mais ce ne sera plus qu’un mauvais souvenir avec le moteur Hermès. Ce dernier va simplement permettre de faire cette étape de compilation au “build” de l’application, lorsqu’on souhaite la déployer sur un store.

Voici deux schémas pour illustrer :

L’équipe de React Native a indiqué que ce moteur allait réduire les temps de lancement de moitié : l’application hybride démarrerais ainsi presque aussi rapidement qu’une application native ! Il y a aussi des améliorations au niveau de l’utilisation de la mémoire ou de la taille du package. Ce moteur est pour l’instant expérimental et disponible seulement sur Android, encore un peu de patience !

JSI

Ce dernier point est bien plus technique. Pour faire simple, le “Bridge” que l’on a vu précédemment va être modifié et amélioré dans une prochaine version de React Native. Cette nouvelle version est appelée “JSI” (pour JavaScript Interface).

Ce Bridge a en effet quelques problèmes liés à son fonctionnement asynchrone. Par exemple, lorsqu’un événement natif comme une demande de scroll est envoyée au code JavaScript, ce dernier va recevoir l’information avec un décalage. Or l’environnement natif n’attendra pas que ce dernier prenne la main pour commencer le scroll, parce qu’il ne peut pas savoir lorsque cela aura lieu. Le natif n’a pas “conscience” de l’existence de la partie JavaScript. Ce délai peut être senti ou visible par l’utilisateur pour d’importantes listes d’éléments.

Le JSI va améliorer cette communication en réduisant la latence et en permettant l’interopérabilité entre les deux univers. Pour faire simple : cela ira plus vite ! Dans un second temps, cette nouvelle interface va permettre de s’affranchir de JavaScriptCore, le moteur JS de Safari. Ainsi, sur Android il sera possible d’utiliser V8 (avec de nouveaux gains de performances à la clé).

Plus d’informations techniques dans cet article sur Medium (où c’était annoncé pour 2020), et sur ce ticket Github pour suivre où ils en sont, car ils ont pris un peu de retard.

Vous pouvez constater les différences avec le schéma plus haut : Yoga sera accessible directement depuis le JSI (gains de perfs) et ce dernier est à cheval entre les deux “mondes”

Conclusion

React Native est donc toujours un très bon choix pour réaliser une application mobile, lorsque les performances ne sont pas un réel critère ou en tout cas non prioritaire. Nous verrons d’ici quelques années les impacts des améliorations en cours, mais d’ici là, si c’est important pour vous, privilégiez plutôt une application native ou Flutter (sujet d’un prochain article). Cette technologie est toujours un bon choix car l’équipe de Facebook reste dans une optique d’amélioration continue sur le sujet. Ce qui reste certain, c’est que le projet avance dans la bonne direction !

Enfin pour ne pas oublier un fait méconnu, il est possible d’intégrer des écrans React Native dans une application native déjà existante. Pratique, si vous avez un gros historique et ne souhaitez pas tout réécrire de zéro, ou si vous souhaitez partager entre les deux OS mobiles une partie seulement d’un nouveau développement. Après tout Facebook l’utilisent eux mêmes avec l’application du même nom, l’onglet Marketplace apparu il y a quelques années est en effet codé en React Native ! Si vous jetez un œil, vous constaterez… que la différence est invisible. Magique !

Les container engines : Podman, l’alternative à Docker

Nous avons vu dans le premier article de cette série ce qu’est un conteneur applicatif et les différentes catégories d’outils qui permettent de manipuler ces conteneurs. Aujourd’hui nous allons nous intéresser à Docker Engine et ses alternatives dans la catégorie des container engines.

Un container engine est une véritable boîte à outils qui permet de faire de nombreuses actions avec les conteneurs : construire une image (build), lancer un conteneur (run), télécharger une image depuis un registre d’images comme Docker Hub ou Quay.io (pull), et bien d’autres. C’est l’outil idéal pour son poste de travail.

Dans cet article nous commencerons par nous intéresser à Docker Engine et les composants qui le constituent. Nous verrons ensuite son principal concurrent dans cette catégorie, Podman. Il existe également PouchContainer d’Alibaba Group, mais celui-ci ne semble pas très actif et la communauté pas très anglophone.

Les rouages de Docker Engine

On ne présente plus Docker Engine, il est la référence incontournable sur le domaine des conteneurs. En revanche, on connaît moins les briques qui le constituent.

Docker Engine est constitué de deux composants majeurs distincts :

  • Le serveur, le daemon dockerd
  • Le CLI docker.

Les deux communiquent entre eux via une API REST. Le daemon se charge de toutes les opérations concrètes, que se soit sur les images, les conteneurs, les volumes et le réseau.

Depuis Docker Engine 1.11 (2016), le daemon dockerd n’est plus monolithique, il utilise le daemon containerd et le runtime OCI runc. Et depuis la release 18.09, Docker peut utiliser BuildKit pour construire les images. Il y a d’autres composants comme SwarmKit, mais nous n’en parlerons pas ici, ce sont des fonctionnalités propres à Docker qui n’ont pas forcément d’alternatives directes.

Containerd a la même architecture client-serveur que Docker Engine avec un daemon, containerd, qui peut être contrôlé depuis un CLI, ctr, ou le plus souvent via son API GRPC. Containerd est un runtime de haut niveau, en tant que tel il ne permet pas de  toutes les fonctionnalités de Docker Engine et le CLI n’a pas pour but d’être utilisé en production non plus. Il faut voir Containerd comme un composant sur lequel bâtir d’autres produits. Ce tableau donne une idée de ce que Containerd permet de faire directement et de ce que l’on peut faire en se servant de Containerd comme brique de base. Vous pouvez voir ci-dessous les briques qui le composent et l’écosystème autour.

Source : containerd.io

Runc est le runtime OCI par défaut de containerd, et donc par extension de Docker Engine. Nous consacrerons un article complet sur les runtime OCI.

BuildKit est une nouvelle implémentation qui remplace le builder original de Docker pour de meilleures performances et quelques fonctionnalités supplémentaires. Il n’est pas activé par défaut pour le moment. Nous avons d’ailleurs consacré un article complet sur les builders d’image !

On peut voir que Docker Engine n’est plus le monolithe qu’il était, ça lui permet de pouvoir faire évoluer indépendamment chaque brique. Et nous allons voir que certaines de ces briques sont utilisées par d’autres outils.

Passons maintenant la main à Podman, le nouveau venu au gros potentiel.

Podman, l’alternative rootless et daemonless

Podman est une implémentation daemonless et rootless de container engine créé par Red Hat. Podman est basé sur les standards de l’OCI et son CLI est compatible avec celui de docker, au point où son adoption est aussi simple que d’exécuter : alias docker=podman.

Le fait qu’il puisse fonctionner en mode rootless et qu’il soit daemonless le rend plus sécurisé par nature comparé à Docker Engine. Il est également plus facile de l’installer sur un poste de travail sans droits d’administration.

Podman n’est pas non plus un monolithe, en interne il utilise Buildah pour construire les conteneurs, et crun comme runtime OCI par défaut. Il s’agit d’un runtime similaire à runc, mais il est plus performant (d’après Red Hat), car écrit en C plutôt que Go.

Certaines fonctionnalités de Docker Engine, comme le mode Swarm, ne sont pas disponibles dans podman.

Il n’est pas non plus possible d’utiliser Docker compose avec podman. Il existe bien podman compose, mais je déconseille son utilisation en production. Il est préférable de se tourner vers des solutions comme K3s ou simplement des services Systemd simples pour déployer de petites applications.

En revanche Podman apporte d’autres fonctionnalités intéressantes comme :

L’adoption de Podman peut permettre une transition plus facile vers Kubernetes, notamment grâce aux pods et à la génération des manifests Kubernetes. Évidemment la génération de manifestes permet de mettre le pied à l’étrier mais ne dispense pas le développeur de connaissances sur l’écriture de ces manifestes.

Il est prévu que Podman et CRI-O partagent la même codebase (libpod) pour les fonctions similaires. Ainsi le même code permettrait de faire tourner des conteneurs à la fois sur un poste de travail et dans un cluster Kubernetes.

Voici un blog post de Red Hat qui introduit Podman et Buildah pour aller plus loin : Podman and Buildah for Docker users. Et un tutoriel pour débuter avec Podman : Transitioning from Docker to Podman.

Conclusion

Comme nous avons pu le voir, Docker Engine n’est pas le seul container engine sur le marché.

Docker Engine est bien installé et a défriché le terrain pour les alternatives maintenant stables. Son découpage en composants comme containerd et runc permet aussi à d’autres produits de voir le jour.

Podman est un concurrent sérieux puisqu’il permet de lancer des conteneurs rootless et daemonless, tout en gardant une compatibilité avec le CLI docker pour une migration toute en douceur.

En attendant le prochain épisode, n’hésitez pas à aller consulter nos précédents articles sur Docker, les conteneurs et l’Open Container Initiative (OCI), les builders d’images OCI : 6 alternatives à Docker mais aussi celui sur comment adopter une approche Kubernetes First !

Pryv et Agaetis, l’humain au cœur de la transformation numérique !

La transformation numérique ne peut, aujourd’hui, ignorer l’aspect humain et le privacy-by-design en est la clé.

Lausanne/Aubière 15 fév 2021 Pryv SA et Agaetis annoncent une collaboration stratégique pour assurer la transformation numérique rapide des industries de collecte de données personnelles. 

En intégrant l’engagement humain, l’ergonomie et l’expertise en matière de security by design, Pryv et Agaetis offrent des solutions de transformation numérique de premier ordre, respectueuses de la confidentialité, et des expériences numériques fluides, mais également plus rapides, à un coût optimisé.

« Ce partenariat est pour nous, Agaetis, une excellente occasion de collaborer sur de grands projets avec Pryv et son équipe à haut niveau d’expertise dans le domaine de la protection des données. Nous sommes des partenaires complémentaires pour répondre aux besoins des entreprises en matière de confidentialité, de la gestion des données associées, de l’édition de la solution à son déploiement. Nos compétences nous permettent de concevoir et de créer des applications sur mesure pour un package complet. », déclare Nicolas Roux, PDG de Agaetis.

2020 et la crise associée à la Covid-19 ont sans aucun doute accéléré la numérisation de nombreux aspects de nos vies, provoquant l’accélération de la bascule technologique. Les plateformes numériques ont dû rapidement évoluer et se développer pour traiter toujours plus de données personnelles clients. Elles sont amenées à absorber de grandes quantités de données utilisateur dans leur système : de la santé numérique jusqu’à la surveillance à distance des patients en passant par l’éducation, l’optimisation des infrastructures et l’analyse du comportement des consommateurs dans presque n’importe quelle industrie. Pour chacune de ces nouvelles offres numériques, un certain nombre de pièges sont à éviter. Négligés, ils entraîneront facilement des conséquences néfastes, d’autant plus dans cette période de tension commerciale où la protection de la vie privée est devenue une priorité pour le monde du numérique.

“Solide, flexible, prêt à l’emploi, voici quelques atouts qui illustrent parfaitement pourquoi nous faisons confiance à la solution Pryv.io. Parfaite si vous souhaitez déployer un nouveau cadre de gestion de données qui gère leur confidentialité, il reste toujours possible de l’adapter à un modèle de gestion de données existant, comme nous avons pu l’expérimenter au cours de l’un de nos projets. Outil open source, il est facile à utiliser et largement documenté. La communication avec l’équipe Pryv, sa réactivité, est d’ailleurs un autre de ses atouts ! Cette solution de gestion de confidentialité fera désormais partie de nos projets. Dans le domaine de la santé bien sûr, mais pas seulement ; nous sommes convaincus qu’elle pourra être déployée sur d’autres secteurs d’activité.” Nicolas Roux, PDG d’Agaetis.

Pour réussir la transformation numérique, la technologie ne suffit pas ! Il est crucial de bien comprendre la relation entre l’Homme et cette dernière pour assurer une transformation numérique durable. Souvent mal comprise, la numérisation centrée sur l’humain ne se limite pas à l’UI et l’UX. 

“Pour offrir une expérience numérique véritablement centrée sur l’humain, il est essentiel de se concentrer sur des concepts clés pour comprendre précisément les besoins des utilisateurs, afin que les avantages surpassent le coût du partage de données personnelles. Il s’agit de la première et de la plus importante des étapes pour la construction de relations de confiance à long terme.” d’après Pierre-Mikael Legris, PDG de Pryv.

“Nous sommes très enthousiastes à l’idée de collaborer avec Agaetis : passionné par les technologies innovantes et cultivant l’intelligence collective, Agaetis intègre ce cocktail à ses productions. La science des données et l’IA font partie de leur ADN. Grâce à notre expertise en matière de confidentialité des données et de couches technologiques pour l’acquisition, la gestion et le stockage, nous pouvons offrir une solution complète de transformation numérique à 360°.”

À propos d’Agaetis : Basée à Paris, Lyon et Clermont-Ferrand, Agaetis est la filiale conseil Data et Innovation du groupe Novencia. Il s’agit d’une grande famille de 400 personnes comptant plus de 60 consultants et experts en data sciences. Agaetis est une entreprise qui porte des convictions et assume ses choix de s’engager pour les secteurs qui façonnent notre environnement de demain : la santé, l’agriculture, l’industrie, la mobilité, la santé et l’énergie. Leurs partenaires et références sont la base de leur expérience, c’est leur force pour conseiller et apporter des solutions pertinentes. Pour plus d’informations, rendez-vous sur : www.agaetis.fr


À propos de Pryv SA : Pryv édite des logiciels essentiels à l’innovation axée sur les données personnelles et sur la santé. Leur intergiciel aide les organisations à gérer les données personnelles depuis leur création jusqu’à leur utilisation, leur partage et leur élimination. Ils accélèrent la mise sur le marché, réduisent les coûts de développement informatique et accélèrent la connectivité à toutes les sources de données. Pryv aborde le droit du citoyen renforcé en vertu du RGPD et transforme le respect de la vie privée en un avantage concurrentiel. Pour de plus amples renseignements, rendez-vous sur le site www.pryv.com.

Lausanne / Aubière 15th Feb 2021 Pryv SA and Agaetis announced a strategic collaboration to ensure the rapid digital transformation in industries collecting personal data. 

Incorporating natural human commitment, usability-centricity and subject matter expertise in privacy-by-design, Pryv and Agaetis deliver best in class digital transformation solutions respectful of privacy and seamless digital experiences, faster, at an optimized cost and right the first time.

« This partnership is for us, Agaetis, a great opportunity to co-work on great projects with Pryv, and its high level of expertise team. We feel that we are complementary partners to address companies’ needs regarding data privacy and its management, from the solution edition to its deployment, its setup. Our competencies allow us to even design and create bespoke applications for a full package. »  says Nicolas Roux, CEO at Agaetis.

2020 and Covid-19 undoubtedly accelerated digitization in any aspect of our lives, making a strong push over the technology tipping point at unimaginable speed. Companies have rapidly started developing digital platforms that process customers’ personal data pumping great amounts of user data into their system: from digital health and remote monitoring of patients, education, infrastructure optimizations and consumer behaviour analysis in almost any industry one could think of. For each of these new digital offerings, there are a number of privacy pitfalls that if neglected will easily lead to very damaging results and loss of business. Meeting the highest privacy regulations became must-have priority for development teams.

“Solid, flexible, ready to use, here are some adjectives that perfectly describe why we trust the Pryv.io solution. Perfect if you want to deploy a data framework managing data privacy, we figured out that it’s still manageable to even adapt it to an existing data management solution, as we experience it with one of our projects. The easy-to-use and heavily documented open-source tool, as well as the good communication with the Pryv team, confirm our choice! We are convinced that we will use this privacy solution in our projects, of course in the healthcare field but we are confident that it could be deployed on others. » says Nicolas Roux, CEO at Agaetis.

Yet, to achieve winning digital transformation, technology is not enough on its own: understanding the relation between humans and technology is crucial to develop sustainable digital transformation. Often misunderstood, human-centric digitalization is not just about engaging UI and UX. 

« To deliver a truly human-centric digital experience, it is essential to focus on key concepts about exactly understanding user needs, so that benefits exceed the cost of sharing personal data. This is the first and most critical step on building trusted, long term relationships.” says Pierre-Mikael Legris, CEO at Pryv “We are very excited to collaborate with Agaetis: Passionate about innovative technology and cultivating collective intelligence, Agaetis integrates this cocktail into its productions. Data science and AI are in Agaetis DNA. Blended with our expertise in data privacy and Pryv.io technology stack for data acquisition, management and storage, we can offer a complete 360 digital transformation solution. »

About Agaetis : Based in Paris, Lyon and Clermont-Ferrand, Agaetis is the Data and Innovation consulting subsidiary of the Novencia Group. It is a large family of 400 people with more than 60 consultants and experts in data sciences. Agaetis is a firm that upholds convictions and takes responsibility for the sectors that will shape our future environment: health, agriculture, industry, mobility and energy. Their partners and references are the basis of their experience, their capitalisation. It becomes their strength to advise and provide relevant solutions. For more information, please visit : www.agaetis.fr

About Pryv SA: Pryv makes essential software for personal and health data-driven innovation. Our purpose-built middleware helps organizations manage personal data from creation to use, sharing and disposal. We accelerate time to market, cut IT development costs and speed up connectivity to all data sources. Pryv addresses the enhanced citizen’s right under GDPR and turns privacy compliance into a competitive advantage. For more information, please visit www.pryv.com

Excel, et après ?

Excel, et après ? Voici une question simple que vous pourriez nous poser en nous appelant ou en nous envoyant un mail pour nous solliciter. Soyons clair d’emblée, beaucoup d’analyses peuvent être menées avec un tableur. Nous l’utilisons d’ailleurs toujours chez Agaetis lorsque c’est l’outil le plus adéquat pour la tâche à accomplir.

Seulement voilà, quiconque doit multiplier des analyses variées avec Excel (ou ses concurrents Open Source) finit par se demander s’il n’y aurait pas parfois un outil ou une façon de faire plus efficace. La réponse en un mot est “oui”, mais elle ne vous apporte pas beaucoup de valeur. La réponse plus complète, elle, nécessite de se poser quelques questions.

Commencer par l’état des lieux de votre écosystème…

  • Qui utilise Excel au sein de mon organisation pour analyser des données ?

Cette première question recense le nombre de personnes potentielles qui basculeraient vers la nouvelle solution. L’accompagnement dans cette transition sera personnalisé si une seule personne est concernée mais sera plus général s’il s’agit d’un groupe de personnes. Dans le cas où des dizaines de personnes sont concernées, un premier groupe devra être identifié pour être formé. C’est ce groupe d’ambassadeurs qui contribuera à la formation ultérieure de leurs collègues.

  • Quelles données sont utilisées (type, volume, accès…) et quels sont les objectifs ?

Lister les données entrantes et les objectifs de chaque analyse donne une vision globale sur les données à ingérer et sur le format des livrables à produire.

  • Qui bénéficie des conclusions de ces analyses ?

Les livrables produits dépendent des personnes à qui ils sont adressés. Cette question évalue également le nombre de personnes à qui sont destinés les résultats des analyses.

  • Quel est le niveau d’expertise et d’appétence de chacun (programmation, mathématiques…) ? 

Ici il s’agit d’évaluer les compétences en interne et les volontés de chacun à se former sur une nouvelle technologie. Cela permet d’estimer un éventuel besoin d’externalisation ou d’orienter vers une solution peu coûteuse en temps de formation.

… pour bien déterminer vers quelle solution vous tourner.


Les deux solutions les plus répandues sont les logiciels de BI et les notebooks. D’autres solutions plus marginales peuvent être envisagées mais nous ne les aborderons pas ici.

Les logiciels de BI (Business Intelligence) sont conçus pour faciliter l’ingestion de données, sa mise en forme plus ou moins complexe, et sa restitution sous forme de visuels poussés (communément appelés dashboard). Ils ont les défauts de leurs avantages : des visuels préconçus nombreux et paramétrables mais peu flexibles, des outils facilitant l’ingestion de données mais limités, un code propriétaire(1) maintenu mais pas modifiable. Ils incarnent donc une suite logique à Excel car ils ne nécessitent pas une formation conséquente pour leur prise en main.

Les notebooks sont des interfaces de programmation interactive. Ils sont généralement structurés autour de cellules qui contiennent chacune des lignes de code exécutables indépendamment ou conjointement. Chaque résultat d’une cellule est directement visualisable : simple opération arithmétique, mise en forme de données dans un tableau, graphique… Cette solution nécessite donc la maîtrise d’un langage informatique : Python, R ou encore Julia parmi les plus connus.

Résumons les avantages et inconvénients de chacun :

Logiciels de BI Notebooks
Prise en mainPlus simple que les notebooks si aucun langage informatique n’est maîtrisé en interne.
Certains logiciels proposent des formations/tutoriels pour apprendre les bases.
Demande une formation préalable dans un langage mais très simple si le langage informatique correspondant est maîtrisé.
Une maîtrise experte dans les deux catégories permettra de visualiser de la donnée plus rapidement à l’aide d’un notebook.
Livrable en l’état C’est l’une des raisons d’être du logiciel BI que de permettre en un clic (ou un peu plus) de rendre accessible son travail à n’importe qui au travers essentiellement d’une page web. Si ce qu’on entend par livrable consiste en un résultat dynamique et esthétique, un notebook ne peut être livré en l’état. Il faudra transformer le code au minimum en une API ou une page web faite manuellement.
Co-construction Il est toujours possible de transférer le fichier au format propriétaire à un collaborateur qui souhaite travailler sur l’élaboration du rapport mais il lui faut une licence et un peu de temps pour comprendre le travail déjà effectué.Le code est facilement lisible et peut donc plus rapidement être retravaillé par une tierce personne.
Aucune licence n’est nécessaire mais il faut tout de même avoir les mêmes bibliothèques d’installées.
CoûtLe logiciel a un coût à l’achat (rare) ou un abonnement mensuel (plus fréquent). Solution gratuite mais le développement peut être long si vous l’externalisez.
Notons à ce stade que les jours facturés sur une telle solution sont en général moins coûteux que pour une solution propriétaire.
AdaptabilitéComme tout logiciel propriétaire, les logiciels BI ont les limites qui leurs sont propres.
Un logiciel BI est tout de même beaucoup plus paramétrable qu’un simple graphique dans un tableur.
Un notebook est tout autant adaptable que le langage informatique qui lui est associé, donc très adaptable
le notebook écrit en Python l’est particulièrement car il s’agit du langage informatique pour lequel le plus de bibliothèques ont été développées pour cette utilisation.

Le choix de l’outil dépend donc en résumé des compétences que vous avez en interne, du budget et du temps à votre disposition pour effectuer la tâche voulue et de la maintenabilité de la solution obtenue.

Choisir l’une ou l’autre de ces familles d’outils n’est pas non plus irréversible. Que vous hésitiez encore entre les deux ou que vous souhaitiez basculer vers une nouvelle solution, n’hésitez pas à prendre conseil auprès d’entreprises spécialisées.

Note :
(1) : Notons qu’il existe quelques logiciels de BI open source (retour au texte)

Docker, les conteneurs et l’Open Container Initiative (OCI)

Plus besoin de présenter Docker, depuis sa création en 2013, il a très vite été adopté et a démocratisé les conteneurs. Incontournable à ses débuts, ce n’est plus le cas; les standards de l’OCI (entre autres) ont permis l’émergence d’alternatives stables offrant d’autres fonctionnalités. Ces alternatives sont tellement solides que Kubernetes a même décidé de déprécier Docker en tant que runtime CRI (Container Runtime Interface) à partir de la version 1.20.

Cet article est le premier d’une série traitant de Docker et de ses alternatives, ainsi que des technologies de conteneurs en général.

Avant d’aller plus loin, commençons par les fondamentaux. Nous regarderons ensuite de plus près Docker et ses usages, puis l’OCI et ses standards.

Qu’est-ce qu’un conteneur ?

Le concept d’un conteneur applicatif est de packager une application et toutes ses dépendances de façon à l’isoler de l’environnement extérieur (l’OS, les autres applications…). Une méthode serait d’isoler cette application dans une machine virtuelle dédiée, mais cette solution est bien trop lourde pour une bonne partie des applications actuelles.

La méthode la plus communément utilisée, notamment par Docker, est d’utiliser les fonctionnalités du kernel Linux de la machine hôte afin d’encapsuler l’application et ses dépendances dans un conteneur pour aboutir à une solution plus légère et performante qu’une machine virtuelle classique. Le conteneur ne contient donc rien d’autre que l’application, ses dépendances et une arborescence de fichiers classiques d’OS au besoin.

Afin d’isoler un maximum le conteneur du reste du système, les conteneurs utilisent une combinaison des fonctionnalités suivantes du kernel Linux.

Les namespaces de différents types, dont :

  • Le namespace de PID : le conteneur ne voit pas les processus de la machine hôte. Les processus du conteneur sont en revanche bien visibles de la machine hôte.
  • Le namespace réseau : le conteneur peut utiliser tous les ports qu’il souhaite sans entrer en conflit avec les vrais ports de la machine hôte.
  • Le namespace de mount : il est possible de monter le système de fichiers et devices que l’on souhaite. La logique est plutôt de réduire les mount au maximum.

Les cgroups permettent de restreindre les ressources CPU et RAM. Si le conteneur essaie d’utiliser plus de CPU qu’il n’en a le droit, il sera simplement limité. S’il essaie d’utiliser plus de RAM, il se fera tuer (OOM Killed).

Les Linux Security Modules (LSM) qui permettent de limiter les appels systèmes. Seccomp, AppArmor et SELinux sont des exemples d’implémentation de ce framework.

La combinaison de ces fonctionnalités permet la création de conteneurs légers et isolés du reste de la machine. Les principaux bénéfices de cette approche sont :

  • La reproductibilité et la portabilité : l’application fonctionnera de la même façon quelque soit la machine hôte puisqu’elle embarque ses dépendances et est isolée de l’environnement extérieur
  • La facilité d’utilisation et de partage : il est très simple de télécharger et de lancer un conteneur
  • La facilité d’administration : le conteneur peut être facilement démarré sur une machine ou une autre et déplacé au besoin

Maintenant que le concept de conteneur applicatif est un peu plus concret, regardons de plus près Docker et ses usages.

Docker et ses usages

Docker est un outil aux multiples usages, il permet entre autres de télécharger des images, de lancer des conteneurs, d’en construire et de redémarrer les conteneurs qui s’arrêteraient inopinément…

Il est également utilisé par des personnes aux rôles diverses, que ce soit le développeur pour tester rapidement une application ou construire localement des conteneurs, l’expert DevOps qui sera en charge de construire les images et de les distribuer dans un pipeline de CI/CD ou encore l’administrateur qui maintiendra le conteneur en production.

Docker est également utilisé par des orchestrateurs de conteneurs tels que Kubernetes.

Face à tous ces usages et profils d’utilisateurs, nous pouvons découper les outils de conteneurs comme ceci :

  • Les container engines : les boîtes à outils permettant de faire un maximum d’actions sur les conteneurs (build, push, run…). Docker étant en tête de liste évidemment
  • Les builders : Docker et ses alternatives sur la partie du build d’image uniquement. Ces outils sont particulièrement utiles dans ces pipelines de CI
  • Les container runtime pour Kubernetes (CRI) : les outils permettant à Kubernetes de lancer et maintenir les conteneurs en marche

Nous consacrerons également un article sur les container runtimes : se sont les outils de plus bas niveau permettant de lancer les conteneurs. Docker n’en est pas un mais en utilise un interne.

Docker permet donc de faire à peu près tout ce que l’on souhaite avec les conteneurs. Les autres outils s’appuient sur les standards basés sur Docker pour venir enrichir le panel d’outils disponibles.

L’OCI et ses standards

Docker et les acteurs majeurs de l’industrie du conteneur fondent l’Open Container Initiative en juin 2015 dans le but de développer des standards. Cette structure est sous la houlette de la Linux Foundation. Docker donne son runtime de conteneur, runc, ainsi que les bases des standards actuels.

Aujourd’hui l’OCI porte deux spécifications : la spécification de runtime (runtime-spec) et la spécification d’image (image-spec).

La spécification d’image définit ce qu’est une OCI image. Elle est composée :

  • D’un système de fichiers en couche : chaque couche représente un changement par rapport à la couche du dessous (ajouts, suppression ou modification de fichiers)
  • D’un manifeste d’image : il contient la liste des couches de filesystem successives spécifique à une plateforme (architecture CPU, OS)
  • D’un index de manifestes : il contient la listes des manifestes d’image pour chaque plateforme supportée par l’image
  • D’une configuration d’image : elle contient les paramètres d’exécution comme les variables d’environnement, les ports exposés, la commande par défaut…
Source : Open Container Initiative

Ces OCI Images sont construites par ce que nous appelons un builder (cf. Docker et ses usages), comme Docker, Buildah ou Kaniko.

Une OCI Image peut ensuite être extraite en “filesystem bundle”, qui sera ensuite lancée par un outil implémentant l’OCI Runtime specification, plus communément appelé OCI runtime ou container runtime.

Une autre spécification majeure existe, il s’agit de la Container Runtime Interface de Kubernetes. Celle-ci sera abordée dans notre prochain article consacré aux implémentations de cette spécification.

Conclusion

Les conteneurs sont maintenant très utilisés, en particulier grâce à Docker. Celui-ci permet de faire beaucoup de choses avec les conteneurs et s’adresse à de nombreux utilisateurs différents. Tous ces usages peuvent être décorrélés et exécutés par d’autres outils grâce aux standards de l’industrie comme ceux de l’OCI, comme le pipe du shell permet de connecter cat et sed par exemple.

D’autres articles de cette série sont disponibles, si vous voulez en apprendre plus sur les container engines ou les builders nous vous laissons les consulter ! D’autres sur les container runtimes et les implémentations du CRI de Kubernetes vont arriver. En attendant le prochain épisode, n’hésitez pas à aller consulter notre article sur comment adopter une approche Kubernetes First

Pour aller plus loin, voici quelques articles qui pourraient vous intéresser :

Bonne année 2021 : les chantiers majeurs autour de vos SI

Bonne année 2021 ! Qui a osé dire bonne année 2020 il y a un an ?

L’année 2020 restera gravée longtemps dans nos mémoires, mais cette fois à cause d’un souvenir partagé par toute la planète.

Ce souvenir commun a bouleversé nos vies personnelles, nos façons de travailler et même nos manières de consommer par moment.

Ces changements majeurs ont mis à rude épreuve les SI de la plupart des entreprises par nécessité de s’adapter au télétravail généralisé, aux impacts business dus aux contraintes sanitaires, voire même aux risques de sécurité engendrés.

Les directions SI ont donc été confrontées à un certain nombre de points de frictions, bloquants pour assurer la continuité des services internes pour leurs employés et la continuité des services externes pour leurs clients.

Les départements « Business » ont, de fait, accru leur demande d’adaptabilité et de rapidité de mise en œuvre de solution ou de contournement pour faire face à cette situation inédite.

Les services informatiques les plus préparés et les plus résilients ont pu répondre à la plupart de ces demandes mais les points de contingence mettent en évidence les transformations internes et structurelles à imaginer et planifier pour les mois à venir.

L’innovation, la modernisation des SI et la digitalisation des expériences, autant pour les employés que les clients, passent par de nombreux axes de réflexion afin d’évaluer les chantiers majeurs de ces transformations.

Agilité et Lean Startup Team

La résilience et la capacité d’adaptation ont été essentielles au cours de ces derniers mois et en particulier pour les équipes IT. Il a fallu réagir vite et de façon coordonnée aux événements inimaginables que nous avons vécus.

Un lien étroit entre toutes les équipes et une méthodologie de projet et de gestion de crise éprouvée ont été les éléments de réussite de cette période. Il a fallu se concentrer sur l’essentiel et traiter les « pains » ou difficultés des utilisateurs finaux en priorité : Piloter par la valeur comment cela se met en place ? 

Quelle est la valeur des projets et des initiatives en cours ? Il est nécessaire de pouvoir les évaluer et les comparer grâce à l’usage de critères communs autres qu’une évaluation de ROI comme la définition de MVP (Minimum Valuable Product) ou une estimation de la valeur des “pains” traités en approche customer centric. 

La philosophie de Test & Learn sur des périodes très courtes ou tout au moins plus courtes que précédemment a démontré son bien fondé et son efficacité dans un environnement instable comme celui des derniers mois :

  • Comment ce genre de méthodologie peut être utilisé et dans quel contexte cela est-il le plus adapté ? 
  • Quelle est la méthodologie de mise en œuvre la plus appropriée à mon organisation, que l’on parle de LEAN ou d’Agile et des cadres Scrum, SAFe, etc… ?

Après avoir choisi le cadre et le périmètre testés, il est tout aussi primordial de lister et de traiter les impacts en dehors de la cellule du ou des projets pilotes : 

  • Quels sont les éléments à prendre en compte en termes de processus RH ou de management d’équipes par exemple ? 
  • Comment les équipes hors périmètre sont incluses ou informées pour que les objectifs de chacun soient atteignables et servent un but commun ?

Tous ces points nécessitent l’analyse du contexte, la préparation du déploiement de ce genre de méthodes, et parfois la revue de certains processus internes ou leur adaptation pour en assurer le succès. Car repenser son agilité ne consiste pas seulement à adopter une nouvelle méthode de gestion de projet avec d’autres rituels, d’autres rôles, et du “visual management” basés sur des post-its.

Data Driven

La nécessité de comprendre les impacts de la Covid-19 sur les clients, les marchés et par conséquent sur les activités internes de l’entreprise a mis en évidence le besoin d’avoir des chiffres mis à jour rapidement et avec un niveau de qualité suffisant pour pouvoir prendre certaines décisions critiques. La data est au cœur de la plupart des considérations : le concept de Data Driven est évoqué voire même revendiqué au sein de nombreuses entreprises mais qu’est ce que cela signifie en termes d’organisation, de processus et de besoins technologiques ?
Il faut prendre en considération plusieurs aspects plus ou moins importants suivant l’utilisation de ces “data assets” :

Quelle est la maturité de la “Data Governance” interne et quels sont les critères  d’évaluation ? 

  • La connaissance des données disponibles en termes de catalogue et de visibilité par les différents départements
  • La définition d’un vocabulaire commun pour parler le même langage
  • L’accessibilité aux metadata, i.e. la définition de chaque type de données, les champs associés et les relations entre ces entités
  • L’accessibilité des données et la gestion de la sécurité associée
  • Le suivi des différentes réglementations associées aux données personnelles comme la RGPD pour l’Europe

Quelle est la qualité des données internes ?

  • Les processus internes mis en place pour assurer la qualité des données
  • Les processus de vérification ou d’alertes pour assurer cette qualité
  • La détection de problèmes sur les données utilisées
  • La gestion des règles complexes et éparses au sein du SI

Comment sont utilisées toutes ces données ?

  • Le pilotage des activités internes
  • L’analyse et la prospection de marchés potentiels
  • Un moyen de créer de nouvelles offres, produits ou services pour monétiser les assets internes

Quelle est l’expérience utilisateur pour les personnes en charge du reporting ou de la création de données à valeur ajoutée, comme les business analystes ou les data scientists ?

  • L’ingestion de données et la data visualisation en “self service”
  • L’accès à la donnée avec une procédure simple
  • La mise à disposition de capacités en termes de stockage, de calcul et d’outils pour explorer les différentes sources de données et en créer de nouvelles

Quels sont les modèles et technologies pour monter une « data platform » adaptée à mon contexte ?

  • Le modèle DataLake & Datamarts traditionnels et leurs alternatives
  • La segmentation des données et les technologies adaptées à chaque type
  • L’intégration avec les systèmes amonts et avals
  • Les contraintes opérationnelles liées à la mise en place d’une plateforme data

Toutes ces questions, et les différents points associés, sont très structurants pour l’adoption de ce modèle afin d’en tirer des bénéfices à court ou moyen terme. 

DevOps & Craftsmanship

Ce besoin d’agilité et de rapidité de mise en œuvre se traduit aussi par la mise en place d’un cycle de développement rapide et efficace. 

Les équipes ont besoin de gagner du temps sur leur processus de livraison pour se concentrer sur les questions d’architecture, de design et d’implémentation :

Quel est le niveau d’adoption de l’approche DevOps au sein des projets ? 

  • Les processus et standards internes
  • L’outillage adapté au contexte
  • Les technologies et les capacités disponibles
  • Les freins à la mise en place

Quel est le niveau de qualité des développements et comment l’améliorer ?

  • Les concepts Craftsmanship
  • Les différents niveaux de tests : TDD, BDD, DDD, ATDD…
  • Les KPIs pour mesurer l’évolution de la qualité

Les phases de mise en place de ces éléments impliquent un investissement initial qui peut paraître lourd et trop coûteux du point de vue du projet car elles sont généralement mal, voire non évaluées à l’initialisation du projet, mais elles sont les bases de la réussite.
L’image et les conséquences qu’entraîne une mauvaise expérience des utilisateurs finaux est sans commune mesure plus préjudiciable qu’un surcoût initial “prévisible”.
Enfin les changements qui seront nécessaires au cours du développement et du déploiement ne seront que plus faciles et gérables avec ces pratiques.

Ces points peuvent faire la différence pour la qualité et la rapidité de mise en œuvre des solutions.

Infrastructure & Architecture Cloud

Les défis du côté de l’infrastructure et de l’exploitation des solutions sont d’autant plus grands que tout ce qui a été évoqué précédemment ne peut se concrétiser sans ces capacités, et que l’évolution des technologies et des besoins est constante.

Déployer vite et de façon robuste, même des services en mode Test & Learn pour des stacks ou technologies non maîtrisés par les équipes internes, est  le challenge des équipes infrastructure qui doivent en parallèle assurer une veille sur les offres cloud toujours plus importante.
En effet, être en capacité de mettre à disposition des services de stockage, de calculs et des capacités réseaux sont les éléments de premiers niveaux, mais les équipes projets sont souvent demandeuses de services plus complexes avec un niveau d’intégration plus élevé.

Enfin, l’accessibilité des services est devenu un enjeu majeur avec la mise en place généralisée du télétravail et les changements associés en termes de mise à disposition et de sécurité.   

Tous ces points conduisent à se poser les questions suivantes :

Comment donner de l’autonomie aux équipes projets tout en gardant le contrôle sur ce qui est mis en place ?

  • Les capacités self-service disponibles et celle à mettre en place pour réduire le goulot d’étranglement de certaines équipes support
  • Les instances et processus de contrôle des budgets infrastructure ou des capacités en self-service disponibles

Comment intégrer des services clouds dans l’écosystème existant ?

  • Les services cloud existants et ceux les plus adaptés au contexte de l’entreprise
  • L’intégration et la sécurité associées
  • La gouvernance de ces services
  • Les impacts, en termes de compétences et RH, sur la mise en œuvre du modèle Hybrid Cloud
  • Les impacts en termes d’outillage pour administrer ce modèle

Comment organiser et déployer une approche DevOps avec les équipes opérationnelles ?

  • Les processus en place ou à définir entre les équipes
  • La conteneurisation des applications
  • La mise en place d’un cluster K8S pour opérer les applications
  • Le monitoring des applications et l’alerting correspondant

Suivant la maturité des services d’infrastructure sur ces questions, certains points peuvent être déjà traités et gérés, mais l’évolution rapide des services cloud mis à disposition par les grands opérateurs implique une gouvernance efficace des services utilisés, et une revue régulière des capacités disponibles.

Sécurité

Comme évoqué précédemment, les questions de cybersécurité sont récurrentes et encore plus importantes sur ces derniers mois avec l’évolution des manières de travailler. De nombreuses entreprises ont dû faire face à des crises de ce type, liées à la situation sanitaire et aux mesures prises rapidement pour permettre à leurs employés de maintenir leur activité à distance.

Concrètement, certaines solutions ou applications n’étaient pas adaptées à la situation, ou pensées en ne tenant compte que des contraintes de sécurité pour une utilisation uniquement interne. 

Comment mettre en place du Security by design sur les projets ?

  • La définition des exigences
  • L’intégration des questions de sécurité dès la phase de conception et de spécifications
  • L’intégration des questions de sécurité dès la phase de conception et de spécifications

Comment faire progresser le niveau de sécurité au sein du SI ?

  • La formation des équipes
  • La sensibilisation sur certains thèmes

Comment connaître les risques de cybersécurité sur le parc applicatif ?

  • La revue des risques majeurs du SI doit être effectuée
  • Le plan d’actions doit y être associé afin de prévoir les opérations à mener

Comment réduire les risques en unifiant l’Identity Management ?

  • L’identifiant unique et les politiques de sécurité associées
  • L’intégration dans les différentes applications pour améliorer l’expérience utilisateur
  • L’administration des utilisateurs et de leurs droits d’accès

Quelles sont les actions préventives et les plans de crise en cas d’attaque du SI ?

  • Les processus ou outils de détection d’une attaque
  • Les modes de mitigation ou de gestion d’une attaque potentielle

Ces premiers points ne sont qu’un aperçu des éléments à prendre en considération et à maîtriser pour assurer un niveau de sécurité essentiel à la gestion de ces risques, qui coûtent énormément aux entreprises en cas d’attaque avérée.

Évaluation de son SI

Pour compléter ces axes de réflexion, il est souvent nécessaire de prendre un peu de recul sur la situation actuelle et mettre en évidence les éléments à traiter en priorité, afin d’assainir certains basiques qui sont un frein à la modernisation ou à l’innovation.

Pour cela, les points suivants sont la base de cette analyse et servent de critères de sélection pour les orientations à prendre :

Cartographie et Audit du SI :

  • Avoir une bonne connaissance et une maîtrise de son SI pour améliorer les prises de décision
  • Analyser les risques en termes de technologie et d’obsolescence des systèmes
  • Évaluer la dette technique et les moyens à mettre en œuvre pour la traiter

Cadrage des programmes de transformation & Roadmap SI :

  • Définir les architectures fonctionnelles, applicatives et technologiques cibles et/ou transitoires des programmes
  • Évaluer les impacts et les efforts de ces transitions
  • Définir les plans de transformation SI, tout en considérant la gestion du changement au-delà du SI ; RH et gestion des compétences, business et expérience utilisateur, opérations et modernisation des méthodes…

En conclusion, cette année, encore plus que par le passé, les entreprises vont devoir se concentrer sur la définition de roadmap ou de schéma directeur SI, en lien avec la stratégie business, pour faire leurs choix d’investissements, particulièrement côté SI. Les éléments cités nous paraissent essentiels, voire obligatoires, pour faciliter l’ensemble de ces choix et la gestion des priorités de cette nouvelle année. 

Si ce sont des questions ou problématiques qui sont en cours de réflexion dans vos entreprises, Agaetis est à votre écoute et peut vous aider à traiter ces sujets grâce à nos compétences et nos offres de service adaptées à votre contexte.

Agaetis vous « souhaite » une bonne année 2021 !

Active Directory, le saint Graal des hackeurs


Il est reconnu dans le milieu du Pentest, du Hacking, que d’arriver à prendre la main sur l’active directory (AD) d’une entreprise est le résultat d’une attaque réussie, une compromission totale. En effet, depuis l’active directory vous pouvez devenir le maître du système d’information. On y trouve de nombreuses informations sur les différents comptes utilisateurs, mais aussi sur les comptes à privilèges. Et comme souvent les mots de passe sont identiques, on peut rebondir d’application en application pour obtenir un black-out complet du système d’information (anéantir les sauvegardes, modifier des bases de données, falsifier des données …). L’AD a survécu aux multiples mises à jour du système d’exploitation, son schéma d’annuaire a évolué avec le temps et continue d’intégrer des ressources qui ne sont plus utilisées, des utilisateurs fantômes voir des comptes à privilèges oubliés….

Il est souvent impacté par les services installés sur le même serveur qui, eux aussi, présentent des vulnérabilités ou des mauvaises configurations introduites par le syndrome du clickodrome.

Malgré les risques élevés sur ce composant du SI, il est souvent peu encadré par des exigences de sécurité

C’est d’ailleurs à ce sujet que le CERT de l’ANSSI a produit un document il y a quelques mois sur des points de contrôles à effectuer sur l’annuaire Windows. On peut se poser la question de pourquoi un tel document ne sort qu’en 2020 alors que les annuaires informatiques d’entreprise existent depuis plusieurs décennies.

Faut-il y voir un mauvais pressentiment de l’ANSSI ? Pour vous aider à gérer cette situation, à la fin de cet article je vous propose des solutions commerciales et open source pour évaluer votre AD et corriger rapidement les différentes vulnérabilités.

Ce document de l’ANSSI permet d’auto évaluer la sécurité et les exigences de sécurité à travers 57 points de contrôles très précis sur la configuration de l’annuaire. Une notation de 1 à 5 est prévue pour permettre de voir rapidement les points à améliorer et bâtir un plan de remédiation avec des objectifs précis.

Des outils pour aider les CISO et RSSI

Dérouler les 57 points de contrôle de l’ANSSI peut être un long travail, surtout si le schéma de l’annuaire existe depuis longtemps et a évolué au fil du temps avec l’arrivée, le départ de collaborateurs et l’intégration de filiales. Plusieurs outils existent sur le marché dans le but d’auditer votre AD avec des objectifs plus ou moins différents. 

Voici une sélection d’outils commerciaux et open source

Isars : logiciel d’audit dédié à l’évaluation des risques en parcourant votre réseau à la recherche de vulnérabilités sur les environnements Windows.

Ping Castle : logiciel d’audit en profondeur de l’annuaire Windows Active Directory.

Isassy : un outil d’extraction de comptes à distance.

BlooDhound : un outil graphique qui permet de voir rapidement les relations entre les différents comptes et groupes d’un active directory.

ADCollector : permet de parcourir rapidement l’arborescence d’un annuaire dans le but de voir rapidement des problèmes de sécurité.

ADRecon : permet d’extraire toutes les informations d’un annuaire et de les exporter dans une feuille Excel dans le but de rechercher des failles de sécurité potentielles.

Pypykatz-mimikatz est l’implémentation en python du célèbre logiciel mimikatz qui permet d’extraire les noms d’utilisateurs et mot de passe/hast NT.

En plus d’auditer son AD il est recommandé de suivre les bonnes pratiques de construction, d’implémentation et d’usage.

10 bonnes pratiques pour une meilleur sécurité de votre AD

  1. Avoir un AD pour les comptes à privilèges
  2. Avoir son AD dans une zone sécurisée
  3. Journaliser les accès et montée de privilèges
  4. Avoir le minimum de services activés
  5. Auditer les configurations des services installés sur le même serveur
  6. Parcourir régulièrement les partages réseau pour détecter des données sensibles accessibles
  7. Parcourir les applications installées avec des droits à privilèges et détecter des mots de passe en clair dans les fichiers de configuration
  8. Changer régulièrement les mots de passe à privilèges
  9. Arrêter les services inutiles sur le serveur supportant l’annuaire
  10. Suivre les mises à jour et avoir un plan de patching établi

Vous voilà désormais armés pour auditer et sécuriser l’un des points névralgiques de votre infrastructure informatique ! Aujourd’hui, la protection de l’AD est essentielle face aux menaces ciblant particulièrement cette brique du SI. Une attention particulière doit être portée à cet actif et, de fait, sa criticité en fait un indispensable dans le plan de protection de l’entreprise.

Lancement de projet agile, comment s’orienter ?

Agaetis vous propose, sous un format packagé, en 2 à 4 semaines, un accompagnement organisationnel pour co-construire les conditions optimales du lancement de votre projet. Nous embarquons l’expertise pour identifier et maîtriser les contraintes liées à votre contexte, puis déployer le socle technologique adapté, avec votre équipe.

Jean-Michel Gourbeau, coach agile chez Agaetis répond à toutes les questions que vous pouvez vous poser autour de cet accompagnement !

En quelques mots, quel est l’objectif de l’offre Scoping360 proposée par Agaetis ?

Cette offre a pour but de permettre à nos clients de disposer d’un package complet et autoporteur pour assurer le lancement d’un projet agile dans les meilleures conditions possibles. Réalisé sur un cycle de temps court, le Scoping360 est une démarche qui initialise et cadre cette première phase de projet.

Lors d’une reprise de projet, d’une refonte, chaque brique composant cette offre sera adaptée aux contraintes et à ce qui doit être conservé de l’existant.

Qu’est-ce qui se cache derrière le terme Scoping360 ? Qu’est ce qui motive cette offre ?

Plaçons-nous au centre de l’espace qui sera dédié à votre futur projet ; de quoi avez-vous besoin ? Qu’est ce qui doit être préparé ? Qu’est ce qu’il ne faut pas oublier ? Ces différents composants, à disposer “autour de vous”, voilà l’essence de notre démarche, l’ADN du projet et le pourquoi du 360.

Nous proposons l’accompagnement organisationnel et embarquons l’expertise technologique pour exprimer, jauger, préparer et affiner le besoin de nos clients, la vision du produit. L’idée est de transformer cet entrant clé en un projet itératif à haute valeur ajoutée, sur un délai de 2 à 4 semaines selon la disponibilité des différents participants.

En synthèse, les objectifs du Scoping360 sont :

  • Assurer le lien entre une idée et son implémentation à venir
  • Engager les parties prenantes sur un objectif commun
  • Déployer le cadre de travail adapté

Dernier point, il est important pour nous d’intégrer et de mentorer notre client dans la préparation et le déroulé de la démarche, pour que ce Scoping360 puisse être rejoué en autonomie.

Comment le cycle du Scoping360 est-il alimenté ? 

L’idée, ou la vision, d’un produit doit servir la stratégie d’entreprise ;  portée par les instances dirigeantes, elle sera un entrant fort de cette démarche. Ce premier lien légitime le projet à venir, en assurant un bon niveau de sponsorship. 

Parmi les autres éléments importants qui viennent alimenter notre cadrage, bien entendu, l’écosystème, son organisation et ses contraintes sont des éléments clés. On intègre aussi d’éventuels retours d’expériences précédentes, et ceux d’une équipe support s’il s’agit d’un produit déjà exploité.

Enfin, un Scoping360 se voulant itératif, les livrables produits, les retours d’expériences, les différents ressentis et les axes d’améliorations identifiés seront autant d’entrants pour une prochaine session de cadrage.

Quelles sont les lignes directrices qui guident cette offre ? 

Passer d’une vision à sa réalisation, c’est d’abord bien orienter son projet. Nous déroulons cette démarche selon trois grande lignes directrices :

Focus produit !

Travailler l’ADN de la solution à réaliser : cela sous-entend d’engager l’équipe métier, cadrer la vision associée et ensuite identifier et impliquer les utilisateurs, autour d’une planification partagée.

Focus technologie !

Identifier les briques technologiques qui composent l’architecture dont nous avons besoin pour servir le produit. Il s’agit également d’identifier une éventuelle dette technique et fonctionnelle, puis d’intégrer notre approche “security by design”.

Focus humain !

Identifier l’organisation d’équipe adaptée, sans superflu, préparer et faciliter sa mise en place. Sa sérénité est clé ; un haut niveau de confiance est une aide précieuse pour atteindre ses objectifs.

Cette offre se découpe donc en plusieurs axes d’actions, quelle est la promesse ? Quelle expertise y est engagée ? 

Reprenons chaque grand axe de travail :

L’ADN de la solution à réaliser

Nous pouvons illustrer ce point avec un entonnoir : nous décomposons une idée en une multitude de fonctionnalités et d’éléments les plus fins possibles… En sortie, tous ces composants sont priorisés et organisés sur une échelle de temps, avec le positionnement des contraintes temporelles et des jalons (si besoin). Nous construisons donc notre roadmap et notre planification.

Sur cet axe, nous engageons notre expertise de coaching Agile, d’idéation, de structuration et de gestion de projet.

Le volet technologique et sécurité

En fonction des contraintes techniques connues et de l’attendu (exemple d’un niveau de performance ou de la pérennité espérée), nous devons définir  les architectures matérielles, logicielles et l’outillage qui seront les plus adaptées. À cela s’ajoute l’audit préalable des usages et la définition d’une stratégie de sécurité. L’ensemble de ces activités aboutissent à la livraison de la documentation technique, fonctionnelle et de sécurité.

Sur cet axe, nous faisons appel à nos expertises d’architecture solution et IT d’entreprise, ainsi qu’une partie de celles de notre offre cybersécurité.

Déploiement d’une organisation adaptée, lean

Généralement en fin de cadrage, nous définissons le cadre de travail Agile, les KPI utiles et la stratégie de gestion des risques, en fonction des contraintes organisationnelles et de l’écosystème opérationnel de l’équipe. Enfin, afin de la structurer, nous définissons ses rituels, ses règles de vie, nous ajustons le périmètre de chaque rôle, la comitologie, la stratégie de communication… Le tout compose la documentation de vie de l’équipe, voire même une partie de son management visuel.

Sur cet axe, c’est l’expertise des coachs et le mentoring d’équipe qui prime, avec l’animation d’ateliers et du conseil sur les outils adaptés.

Pour rentrer dans les détails, en quoi consiste le scoping d’un produit ? 

C’est un cheminement qui se déroule via une séquence d’ateliers de travail : de la vision macro à l’activité opérationnelle, en passant par la construction d’un lien renforcé entre équipes métier et IT, alignées sur un objectif commun.

Première étape: rassembler les participants clés du futur projet, même si les membres de l’équipe qui réalisera le produit ne sont pas tous connus. Ensemble, nous planifions dans le détail chaque atelier, en identifiant quelles parties prenantes du projet il est pertinent et constructif d’inviter. À chaque étape du Scoping360, un ou plusieurs livrables seront produits, sur mesure pour le projet et le client dont il est question.

De ce point de départ, le coach responsable de l’ensemble du cycle prépare et anime les différentes sessions de travail, il les adapte et il itère si besoin. Au moins une personne de l’équipe client participe à ces phases préparatoires et aux animations, aux présentations, aux restitutions. L’objectif est pour nous de transmettre les bases du savoir-faire nécessaire, induire de la confiance et un processus d’autonomisation sur cette pratique.

Pourquoi est-il primordial de savoir organiser son projet agile ? 

Une organisation soignée dès le départ permet de créer une base solide, d’éviter des pertes de temps, un certain nombre d’incompréhensions et de frustration par la suite. Cela semble simple mais c’est une étape à anticiper et à ne pas rater, particulièrement avec nos processus itératifs qui atteignent des rythmes soutenus. 

Voici quelques gains, communs aux expériences réussies :

  • Une maîtrise forte de ce qui est produit par l’équipe
  • Une limitation des incertitudes
  • Beaucoup de sérénité, chère au focus humain évoqué plus haut (et nos principes d’agiliste)

Il faut savoir investir ce temps de cadrage et de préparation pour ensuite en gagner et assurer la réussite du projet.

Au passage,  le pilotage de projet se doit d’entretenir la confiance entre les parties prenantes, via une grande transparence et le maintien d’échanges constructifs, garants de cycles vertueux.

Quel est l’intérêt de l’offre Scoping360 pour un projet ? 

Au lancement d’un projet Agile, d’autant plus si c’est le premier, il est souvent compliqué d’identifier les actions à mener pour garantir les meilleures conditions de travail pour son équipe. Notre offre Scoping360 apporte ce package complet, cette base organisationnelle nécessaire, avec l’accompagnement de nos coachs en incluant l’expertise de nos experts et de nos architectes. L’accompagnement est, pour nous, indissociable de cette démarche et garantit en grande partie son succès. 

Enfin, le mentoring permet d’aller plus loin qu’une simple prestation. C’est à nos yeux tout aussi enrichissant et important de partager les clés de cette pratique.

Quelles sont les clés d’un cadrage 360 réussi ? 

Plusieurs facteurs facilitent le bon déroulement d’un Scoping360. 

Un soutien fort de l’équipe dirigeante est plus qu’important, cela légitime la démarche et le projet à venir. Autre point d’attention : il faut s’assurer de l’implication des parties prenantes et que les participants disposent du temps nécessaire au succès des ateliers.  La valeur du Scoping360 n’en sera que plus grande si un climat de confiance se crée pour promouvoir et protéger des échanges constructifs.

Par ailleurs, si nous devons déterminer les marqueurs de réussite d’un tel cadrage, le premier serait l’alignement et la compréhension de tous sur la vision, que tous aient compris pourquoi ce projet se lance, qu’il ait du sens pour l’équipe de réalisation. En plus d’une mise en confiance pour produire dans de bonnes conditions, les liens sont renforcés entre équipes métier et IT, avec des pratiques partagées, dans un esprit de co-construction. 

Autre indicateur de réussite : des managers qui adoptent une posture de soutien, de proximité avec l’équipe, plus que la simple validation d’une idée business, d’un budget et de contrôle de la production.

Et pour terminer, pourquoi choisir Agaetis pour m’accompagner dans mes projets agiles ? 

Chez Agaetis, notre guilde d’agiliste, particulièrement nos 3 coachs expérimentés maîtrisent la démarche et l’accompagnement des équipes projet agile. Au-delà des échanges, challenges et de l’entraide que cela induit, ils savent activer et utiliser l’ensemble des offres que propose notre entreprise, adaptées au projet qui se lance. 

Software Craftsmanship, Data Storming, Piloter son Cloud, Cybersécurité, Adopter K8S… en sont quelques-unes.

Le Story Point n’est pas Scrum ; bonne pratique ou illusion ?

La majorité des activités de nos sociétés modernes est régie par des systèmes numériques. Les chiffres et les nombres pilotent notre quotidien et constituent le socle de la gestion de projet. Le scrum, ce cadre de travail agile aux pratiques claires, avec ses cérémonies et ses rituels, n’échappe pas à la règle. 

Lors d’une récente expérience professionnelle, une équipe Scrum a dû évoluer, s’adapter et pallier au départ de son PO. Dans ce contexte déséquilibré, certains repères habituels, notamment les story points, ne faisaient plus sens dans le processus de production. Pour autant, cette équipe a réussi à revenir à l’essentiel, redéfinir ses pratiques et travailler en co-construction directe avec les équipes métier. Cette expérience est le point de départ de cet article et a nourri cette réflexion autour de l’estimation numérique. 

Aujourd’hui, pour la majorité des équipes, le story point semble être le socle numérique pour le suivi et la maîtrise d’un projet. Mais qu’en est il de ses origines, ses liens avec le produit, ses apports mais aussi ses inconvénients… Faut-il continuer à utiliser le story point ? 

Back to basics ; c’est quoi un story point ?

Dans le monde de l’Agilité, adaptée à l’IT, il est commun d’estimer l’effort nécessaire pour construire une fonctionnalité ou réaliser une tâche. Si l’on met volontairement de côté les estimations de type « dimensionnement », telles que les tailles de T-shirt, un système numérique comporte de nombreux avantages :

  • Être en mesure de calculer un ROI approximatif, comme le rapport entre la somme des estimations de tâches, en unité de temps, et le gain chiffré d’une fonctionnalité
  • Définir le potentiel d’une fonctionnalité, comme le ratio entre la valeur métier d’une fonctionnalité et l’effort nécessaire pour la produire

Élément numérique clé en Agile, le story point (SP) est une unité de mesure composite, couramment utilisée. Derrière cette dénomination, chère au jargon des agilistes, se cache un mix de plusieurs concepts :

  • La complexité technique à produire
  • La durée de réalisation
  • L’incertitude ou le risque embarqué pour cette réalisation

Quantifier et synthétiser ces éléments en une seule valeur nous simplifie l’existence. Au-delà de faciliter un calcul de potentialité ou un ROI, évoqués précédemment, le story point permet d’évaluer relativement les fonctionnalités, les unes par rapport aux autres. L’équipe détermine la valeur en story points d’une fonctionnalité qu’elle maîtrise parfaitement, et évalue les suivantes en fonction de cette dernière. 

Soit dit en passant, cette valeur étalon importe peu et sera propre à chaque équipe, comme le reste de l’échelle de notation.

Bien que l’on puisse utiliser une échelle de valeurs via une notation sur 10 ou un pourcentage, c’est généralement la suite de Fibonacci adaptée qui est associée au story point Agile. Déclinée sous un format de carte de poker pour une utilisation facile en équipe, on la retrouve donc sous la forme suivante: 0/0.5/1/2/3/5/8/13/20/40/100…

A noter que l’utilisation de cette échelle numérique est d’ailleurs corrélable avec la durée d’une itération, d’un sprint. On constate qu’en travaillant sur des cycles courts (2 semaines), naturellement l’équipe n’utilise pas les grandes valeurs, ce qui induit et valorise le travail de découpage du product owner et la gestion fine de son backlog de produit.

Story Point versus Scrum !

Lorsqu’une équipe travaille en respectant le cadre Scrum, il est généralement admis et accepté sans condition particulière que le story point est utilisé pour estimer les éléments du backlog.

En plus de concrétiser les notions d’effort, de complexité et d’incertitude, son format numérique est également pratique en termes de gestion de projet et facilite la mise en place des indicateurs associés. Le story point devient la base du calcul de la vélocité d’équipe, sa prédictivité, sa productivité, etc. Il permet même la construction du burn up chart, assurant au product owner le suivi de l’évolution de son backlog, donc l’avancement de la construction du produit.

Finalement, en Scrum, le story point est de facto associé au backlog, à l’échelle des fonctionnalités, à l’instar de l’unité de temps qui est utilisée pour chacune des tâches opérationnelles de l’équipe.

Facilitant le story point ? Assurément…. Mais si l’on revient aux basiques, à la littérature et notamment le Scrum Guide de Ken Schwaber et Jeff Sutherland, le story point, cet élément si commun aujourd’hui, n’est pas du tout mentionné. Seule l’estimation des tâches est une pratique décrite dans le document. Ce constat pousse à la réflexion autour du lien entre l’agilité au sens d’état d’esprit, et cette gestion très chiffrée que l’on fait de Scrum aujourd’hui.

Un story point, oui mais…

À l’échelle d’une fonctionnalité, la combinaison des complexités, durées et incertitudes est généralement difficile à déterminer pour une équipe. Bien que l’attendu ne soit pas une science exacte, ce besoin de traduire en temps et en coût au plus tôt nous amène à apporter plus d’importance aux story points donnés à chaque élément de backlog, en oubliant un peu qu’il s’agit d’une estimation complexe, mais qui est surtout relative, appuyée et confirmée par ce qui est déjà produit.  

Ce système numérique rassure ; il est concret, familier et paraît simple. L’équipe et son product owner développe une confiance excessive envers cette pratique (biais de la loi de l’instrument), le story point se substituant même à la valeur métier.

Puisqu’on attend d’elle un chiffre ou un nombre, l’équipe va naturellement se concentrer sur ce qu’elle peut quantifier, à savoir une durée et un effort à produire, reflétant la complexité. Naturellement, ce biais d’ancrage influence la prise de décision de l’équipe. L’incertitude (ou le risque), notion abstraite, se retrouve peu dans ces estimations chiffrées. C’est d’ailleurs souvent ce qui amène aux nombres les plus forts de la suite de Fibonacci (40 et 100), qui provoque ensuite une crainte quant à l’implémentation de ces éléments.

L’Agile met en avant l’empirisme, la confiance et les sentiments, or avec une telle dérive du nombre, on observe une baisse de la compréhension naturelle de l’équipe. Victime d’un biais de justification du système, elle fait le focus sur l’exactitude de son estimation, dédie une part de son énergie pour les améliorer, plutôt que de garder son attention sur le produit.

Cette perte de sens autour du produit amène l’équipe à travailler au service de ses indicateurs basés sur le story point, un résultat de vélocité devenant l’objectif principale d’une itération (biais d’actualisation hyperbolique).

Dernier point lié au management, les indicateurs de productivité, facilement calculable à partir du story point (estimation parfaitement inexacte) deviennent un levier de pression et de contrôle. Ce biais d’autorité est néfaste pour le fonctionnement d’une équipe qui subit un système de punition/récompense, plutôt que de profiter d’un climat de confiance. Dans les cas les plus grave, par la crainte du jugement du management, un biais de négativité se développe, bridant ainsi la capacité de progrès et d’innovation de l’équipe, au profit d’un résultat chiffré en fin d’itération et au dépend parfois de la satisfaction de l’utilisateur.

Stop aux story points ?

Cette réflexion amène naturellement la question du #NoEstimates. Il n’est pas ici question d’arrêter purement et simplement l’estimation des fonctionnalités à produire, mais plutôt de stopper un dimensionnement numérique des user stories, revenir ainsi à la priorisation métier et la valeur ajoutée du travail engagé.

Plus simple, pleine de bon sens, cette pratique ne répond plus au besoin de savoir, d’estimer, combien le développement du produit va coûter et sa durée… Mais cela n’est-il pas le propre de l’agilité ; fixer en amont budget et délai, pour se concentrer pleinement sur la priorisation pour maximiser la valeur ajoutée ?

Alors oui, pour assurer le suivi au product owner, informer le management et les sponsors, il est nécessaire de revoir les indicateurs utilisés et les construire à partir d’élément plus simple comme un simple comptage du nombre de user stories.

Avec de l’accompagnement, l’expérience et un niveau de maturité suffisant, une équipe pourra se passer du story point mais ce dernier reste rassurant pour une équipe jeune, et viendra parfaitement compléter le cadre Scrum.

En conclusion, l’utilisation du story point est une pratique répandue et particulièrement utilisée avec Scrum puisqu’elle apporte le socle chiffré nécessaire. Devenu commun, le story point semble faire partie du cadre, sauf que le scrum guide n’y fait jamais mention et ce qui apparaît comme un élément facilitant, peut rapidement devenir encombrant et limitant. L’équipe dont il était question dans l’introduction devait évoluer et s’adapter pour faire face à un contexte déséquilibré.

Pratique pour une Scrum qui se construit, relativement facile à enseigner, l’utilisation des story points est rassurante pour tout l’écosystème. Mais, accompagnée par un coach ou son manager agile,  il est important qu’elle soit en capacité de challenger naturellement ses pratiques en toute confiance. Elles doivent être challengées régulièrement, adaptées, voire même délaissées, moyennant les adaptations nécessaires afin de ne pas léser les autres parties prenantes de l’écosystème de l’équipe. Ne parle-t-on pas de lever les contraintes et d’adaptation au changement lorsque l’on pratique l’agilité ? 

Comment enclencher le chrono tout en sécurisant le Time to Market ?

Les projets de R&D ou d’innovations s’appuient de plus en plus sur des outils ou des solutions informatiques pour leur valorisation vers le monde économique. L’objectif de création de valeur et d’activités sur la base de ces travaux, demande une sécurisation des produits et des services issus de ces projets.

Cette phase d’industrialisation peut être ralentie, ou ne pas aboutir, si le produit est trop éloigné des standards informatiques du marché.

Les objectifs que nous poursuivons à travers nos prestations répondent à plusieurs desseins pour augmenter la probabilité de succès en maîtrisant les risques et en diminuant le Time to Market.

En collaborant avec les chercheurs nous leur permettons de se focaliser sur le cœur de leur savoir tout en co-construisant les outils numériques.

Nous poursuivons une vraie ambition, réussir la valorisation rapide des innovations dès les phases de développement. 

« Houston we have a problem » : Pourquoi je n’atteins pas mon marché ?

  • Une technologie inadaptée ou obsolète
  • Une sous-évaluation économique du plan d’industrialisation
  • Un ramp up des effectifs et de l’organisation mal maîtrisé
  • Une stratégie marketing et commerciale qui adresse un segment de marché non mature
  • Une mauvaise valorisation de la propriété industrielle
  • Une perte de confiance des investisseurs pour accompagner le passage à l’échelle

« One, two, One, this is just a test » : Nos préconisations technologiques pour accompagner la réussite du projet

Pour s’assurer de délivrer des solutions facilement interfaçables et intégrables dans l’écosystème technologique du marché, il est nécessaire de travailler sur une optimisation globale, notamment les algorithmes, les IHM et s’assurer de proposer des logiciels robustes et documentés. 

  • Adopter une démarche de programmation s’appuyant sur le manifeste du Craftsmanship pour garantir la qualité, la fiabilité et la maintenabilité des applications tout au long de leur cycle de vie.
  • Prendre en compte les exigences du Security by Design sur l’architecture et le logiciel proposé, pour limiter les failles et la vulnérabilité de la solution, est un impératif.
  • Privilégier un pilotage du projet en co-construction, basé sur les pratiques agiles pour s’assurer, à chaque étape du plan d’industrialisation, de dérisquer rapidement et réorienter la roadmap si besoin.

Une approche 360° du projet est nécessaire pour le passage à l’échelle de la stack et de la direction technique. Elle permet de mettre en place l’organisation de demain et de répondre aux évolutions technologiques.

Qui est concerné ?

Les laboratoires de R&D, les industriels portant ou recevant l’innovation, les start-up souhaitant lever des fonds, sont de potentiels partenaires.

Lorsque les cellules de R&D académiques souhaitent déployer leurs travaux vers le marché (c.-à-d. Early Market), elles peuvent avoir besoin de standardiser et diffuser les outils numériques à une large échelle, notamment au passage sur le “vrai” marché (c.-à-d. Mainstream market).

Les industriels récepteurs des travaux de R&D ont la nécessité de s’assurer qu’en termes d’exploitation la solution est robuste, interfaçable et facilement maintenable.

Exemples de cas ayant bénéficiés de l’accompagnement d’Agaetis

  • Développement d’une application pour l’optimisation des conditions de coupe en usinage, pour les portes d’avions basé sur les algorithmes génétiques
  • Consolider et optimiser un algorithme d’optimisation dynamique d’un schéma de réseau de distribution d’énergie issue d’un projet de recherche pour une ELD
  • Optimiser et industrialiser la version prototype d’un jumeau numérique permettant de proposer un dimensionnement optimal de l’hôpital en “lits chargés” (nombres de lits ouverts par service et par semaine)

Adopter une approche Kubernetes First

L’utilisation des containers est un sujet au cœur de l’actualité du monde informatique et de la sécurité ; ils sont de plus en plus utilisés dans les environnements de production. De nombreuses entreprises ont opté pour une solution Containers as a Service (CaaS) pour simplifier et mettre en œuvre leurs exigences d’infrastructure spécifiques pour répondre à leurs enjeux d’innovation et d’agilité. 

Dans le cadre de son offre “Adopter Kubernetes”, Agaetis propose de vous accompagner dans votre transition vers ce système open source dans le but d’automatiser le déploiement, la mise à l’échelle et la gestion de vos applications conteneurisées.

Pierre Pironin, architecte cloud et expert Kubernetes chez Agaetis, répond à toutes les questions que vous pouvez vous poser autour de cette solution.

Pour commencer, quel est l’intérêt des containers pour une infrastructure ?

L’intérêt principal des containers est de fournir une couche d’abstraction entre les applications et l’infrastructure qui les héberge. Ainsi chacun de ces deux écosystèmes peut évoluer à son rythme, sans être dépendant du cycle de vie de l’autre. Par exemple, la montée de version d’une bibliothèque se fait localement au niveau de l’application, sans besoin ni contrainte sur l’infrastructure. 

En quelques mots qu’est-ce que Kubernetes (K8S) et qu’est-ce qui le différencie des autres solutions du marché ?

Les containers seuls ne peuvent garantir le passage à l’échelle dès lors que le SI d’une entreprise devient conséquent. Pour cela, on a besoin d’un orchestrateur de containers qui va venir piloter le cycle de vie de ces containers. Et sur ce point, Kubernetes s’est imposé depuis plusieurs années comme LA solution d’orchestration incontestée. 

Soutenu par l’une des plus importantes communautés open source au monde, il a su rallier ses concurrents à sa cause afin de fournir au monde informatique un standard commun à tous, où les énergies de chacun poussent globalement dans le même sens.

Concrètement, qu’est-ce que Kubernetes apporte à l’organisation d’une infrastructure ?

De par ces capacités de self-healing, de load balancing et de gestion efficace des ressources, Kubernetes apporte naturellement résilience, haute disponibilité et scalabilité aux applications. Ces propriétés sont la clé de succès pour garantir à l’utilisateur final une expérience optimale, une efficience des équipes de développement pour déployer ses applications, ainsi qu’une maîtrise fine des coûts d’infrastructure.

Quels sont les défis à relever pour opérer une transition vers une approche Kubernetes first ?

Les promesses portées par un système tel que Kubernetes ne sont pas neutres en termes de coût, aussi bien d’un point de vue humain que des ressources à déployer. 

Il faut réfléchir dès le début au fait de vouloir internaliser, ou non les compétences, comment déployer Kubernetes, car il existe une infinité de possibilités adaptées à chaque besoin : 

  • Comment l’intégrer à l’écosystème existant comme par exemple la stack de monitoring et la chaîne de CI/CD
  • Comment élaborer une stratégie de communication pour former une communauté K8S en interne

Quelles sont les étapes clés de cette transition vers Kubernetes ? 

Il faut que cette transition vers Kubernetes soit douce, réfléchie et adaptée au besoin. Le fait que Kubernetes soit à la mode et très exposé médiatiquement n’est pas une raison suffisante pour en faire un choix technologique pertinent.

Cette transition doit être une véritable adoption, en partant d’une phase d’étude où l’on se pose les bonnes questions, suivie d’un pilote pour se tester et valider les hypothèses initiales. Une fois l’opportunité démontrée, il s’agira d’atteindre rapidement une masse critique afin d’amortir le “ticket d’entrée” et enfin de pérenniser la plateforme pour l’intégrer pleinement dans le monde Cloud Native.

Comment Agaetis accompagne les organisations désireuses d’adopter la solution Kubernetes ?

Forts de notre expertise et de nos expériences Kubernetes chez nos clients, nous avons décidé, chez Agaetis, de capitaliser ce savoir-faire dans une offre “Adopter Kubernetes” afin  de proposer différents accompagnements aux entreprises se posant la question d’oser Kubernetes ou non.

Cette offre repose sur un accompagnement de bout en bout (Be Ready, Test & Learn, Grow, Enrich) afin d’aider les entreprises à se poser les bonnes questions, mesurer les investissements, les aider à démarrer lorsque Kubernetes s’avère un choix pertinent, pérenniser la plateforme (notamment d’un point de vue sécurité) et bien sûr former les utilisateurs. 

Le tout dans une volonté de co-construire à chaque étape afin de permettre une véritable montée en compétences et une appropriation de la technologie par nos clients.

Risques cyber, le plus dur est devant nous…

Les conséquences de la crise du Covid et du confinement forcé sont pour l’instant peu visibles dans les budgets des DSI. Toutefois une forte crainte de réduction de budget pèse sur les budgets SI pour 2021 avec des conséquences directes sur leur fonctionnement et notamment pour ce qui est lié à la sécurisation des systèmes d’informations ayant vécu une transformation plus ou moins aboutie depuis Mars 2020.

Une gestion de crise à marche forcée

L’un des premiers objectifs lors du confinement a été pour les entreprises de garder une activité en s’adaptant à la contrainte de ne pas être physiquement dans leurs locaux. Si certaines entreprises étaient préparées ou avaient déjà engagé des moyens d’accès au SI depuis l’extérieur, d’autres ont dû faire face à un besoin d’accès aux ressources informatiques de l’entreprise depuis des lieux inhabituels.

Elles ont été confrontées à gérer rapidement différentes problématiques :

  • Ouverture du SI à l’ensemble de l’entreprise
  • Adaptation des droits et privilèges
  • Données partagées et accessibles sur des équipements personnels
  • Partage des informations avec des sous-traitants et tiers

Des solutions plus ou moins adaptées

Peu préparées à gérer cette crise, les entreprises ont dû répondre dans l’urgence avec des solutions techniques et dépenses engagées sans réflexion. L’objectif principal fut de répondre au besoin d’accès de l’information afin de ne pas ralentir ou bloquer l’activité de l’entreprise.  Les exigences de sécurité initiales non pas toujours été respectées, voire contournées, pour laisser place à des solutions non qualifiées, avec des exigences de sécurité faible, quand certains SI se voyaient même déjà infiltrés par des pirates.

Exemple Zoom : L’application de visioconférence Zoom s’excuse pour des failles informatiques

Toutes les entreprises n’ont pas le même niveau de maturité en cyber sécurité sur l’ouverture et l’accès de son SI vers l’extérieur.

Les habitudes prises lors de la phase de gestion de crise seront difficiles à changer, de même pour les retours arrières qui seront eux presque impossibles. Il sera alors nécessaire d’intégrer ses nouvelles expositions vers le monde extérieur dans son plan de défense du SI. Pour les entreprises ayant déjà engagées des processus de gestion du SI (ISO 27001) il sera alors facile d’intégrer ces nouveaux usages et services. Pour les autres il est vivement conseillé d’établir un audit précis du SI, sa sécurité et de mesurer le niveau de risque sur ces nouvelles habitudes.

Pour réduire les risques, les investissements seront nécessaires, car les nouveaux usages et nouveaux services ont déplacé les enjeux de sécurité.

Les enjeux d’une sécurité autour du zéro trust seront accélérés par les besoins d’accès aux services et du partage de l’information. Un nouveau paradigme apparaît avec le contrôle des équipements, des habitudes et des services en périphérie du SI. Les investissements en sécurité réalisés ne sont ou ne seront pas capables de garantir une vision à 360° du niveau de sécurité de l’entreprise. 

La crise sanitaire a permis de gagner entre 2 et 3 ans en maturité digitale dans certains secteurs. Pour autant les exigences de sécurité et la couverture des risques ne se sont pas adaptées à la même vitesse que les métiers. 

Les nouveaux enjeux seront focalisés sur la protection du poste client et sa conformité, de l’analyse comportementale et le renforcement du principe du moindre privilège. De nouvelles sources de journaux seront générées, liées aux applicatifs et équipements de sécurité pour prendre en compte la sécurité périphérique. Cela implique une gestion centralisée de ces événements avec des objectifs de détection des menaces et comportements anormaux.

Des enjeux vers l’automatisation

Le monde de la sécurité devra apprendre vite et s’adapter à ses nouveaux besoins, hébergés dans des infrastructures hybrides voir collaboratives. Le niveau de confiance donné aux utilisateurs et à leurs pratiques sera un élément clé dans la réussite de sécurisation du SI.

Notre réponse : réduire les coûts en apportant des solutions alternatives.

L’empilement de briques de sécurité n’est pas gage d’une sécurité maîtrisée à 100 %. Aujourd’hui il est difficile de maîtriser pleinement les solutions techniques déployées sur son infrastructure qui sont souvent configurées par défaut ou avec des templates non adaptés aux enjeux et actifs à protéger dans les entreprises. C’est pourquoi nous avons décrit une approche à base de solutions open source pour permettre au TPE, PME, ETI de pouvoir accéder à des solutions technologiques pour véritablement établir un plan de défense de leur SI robuste et adapté au contexte des entreprises. 

Nous vous invitons à prendre connaissance de notre vision d’un plan de défense aux meilleurs coûts.

Nous l’avons baptisé plan Marshall pour permettre une gestion des cyber risques accessibles à tous ! 

Progressive Web App (PWA) : explications et cas pratique

Chez Agaetis nous pensons que les PWA sont une alternative performante à une partie des applications natives. Ce sont des programmes que l’on peut installer sur un ordinateur, un smartphone, aussi appelés client lourd (ex : Word ou WhatsApp). 

Pourquoi une alternative ? Elles ne demandent pas de processus d’installation, de mises à jour manuelles et fonctionnent sur tous les appareils quel que soit le système d’exploitation.  

Notre site web est désormais une « Progressive web App » (PWA), un cas concret parfait pour expliquer la technique et détailler les avantages et inconvénients.

Qu’est-ce qu’une Progressive Web App ?

Le terme PWA désigne un concept ou une norme d’applications web, poussé par Google. À l’origine, la légende dit que Steve Jobs est le premier à en avoir eu l’idée peu après l’apparition de l’IPhone en 2007. Mais c’est bien un concept poussé par Google de nos jours avant tout, à travers Chrome (en réalité Chromium et tous ses dérivés évidemment). Le concept est encore très récent mais se développe de plus en plus, Firefox et Safari implémentent d’ailleurs les mêmes fonctionnalités pour suivre.

Des PWA de sites connus ? Twitter, Spotify, Instagram ou encore Pinterest. Chacun de ces sites a communiqué une amélioration des taux de conversion suite à l’implémentation. Pourquoi ? Parce qu’une PWA c’est avant tout un cache sur l’appareil de l’utilisateur, il y a donc un gain de performances. Mais c’est aussi bien plus que cela !

Une PWA c’est un site web installable qui peut fonctionner en hors ligne

Concrètement, on installe la PWA sur un PC ou un smartphone et elle peut fonctionner hors ligne. Préalablement il faut accéder au site pour qu’il soit mis en cache, ce n’est pas magique !

N’étant pas réellement installée, la PWA prend moins d’espace pour son fonctionnement et s’exécute plus rapidement. On ajoute une simple icône qui permet de pointer vers la web app. Elle donne l’impression d’utiliser une application native alors qu’elle fonctionne à travers le navigateur. La PWA n’a pas besoin d’être téléchargée ou maintenue à jour.

Un site qui implémente la norme PWA a l’autre particularité de pouvoir accéder aux commandes « natives » de nos systèmes d’exploitation, comme la caméra sur smartphone, le Bluetooth, ou encore les notifications. Il est nécessaire de donner l’autorisation au préalable tout comme une application native.
N’importe quel site ou application Web peut être converti en PWA : un WordPress, une application React ou encore un site PHP « old school » (MVC). Cet ajout est plus utile pour une application web que l’on souhaite rendre accessible sur mobile, plutôt que pour un site vitrine. On note tout de même un gain de performance important sur les pages déjà parcourues, plus la possibilité de pouvoir « sauvegarder » un article ou une offre pour y accéder en hors ligne (pour le lire dans le métro par exemple).

Exemple concret avec le site d’Agaetis

Pour mieux comprendre voici un exemple concret avec ce site, qui vient tout juste de devenir une PWA.

Première connexion sur le site : ce qu’il se passe dans les coulisses

La première fois que vous accédez au site, il est chargé normalement comme tout autre site Web. Cependant à la fin de ce chargement initial, un fichier spécial appelé « service-worker.js » va être téléchargé et activé dans votre navigateur. C’est ce fichier qui opère la « magie » pour que les PWA soient possibles. 

Si vous rafraîchissez la page, votre navigateur va retélécharger tous les fichiers qui la composent depuis notre serveur. Cette fois-ci le service-worker enregistrera la plupart de ces fichiers dans votre navigateur. Nous gardons toujours la main sur la configuration et ce qu’il doit enregistrer de façon transparente et invisible pour vous. 

C’est là qu’il va devenir utile, si vous rafraîchissez la page encore une fois, les fichiers du site seront servis depuis le service-worker et non plus depuis le serveur. Vous permettant ainsi de gagner toute la latence induite par une requête sur Internet. Pour un seul fichier le résultat peut sembler maigre, mais si votre navigateur a besoin de 10 fichiers interdépendants, ou plus comme ici, vous gagnez rapidement 1 seconde sur le chargement de la page ! C’est à partir de là que le mode hors ligne est rendu possible.

À noter qu’en parallèle, le service-worker va effectuer les vraies requêtes sur notre serveur pour récupérer d’éventuels changements de contenu et au cas échéant, mettre à jour son cache. Vous aurez ainsi accès aux nouveautés au prochain rafraîchissement (ou lorsque vous réaccéderez aux pages correspondantes). Si le site en lui-même est modifié il vous affichera un message vous informant qu’une mise à jour est disponible.

Chaque page que vous parcourez au préalable est mise en cache et accessible en hors ligne

Maintenant que les fichiers sont mis en cache, si vous perdez la connexion, la page sera toujours accessible même si vous la rafraîchissez ou si vous avez fermé l’onglet et le rouvrez. Vous pouvez essayer vous-même en déconnectant volontairement votre ordinateur/smartphone (mode avion par exemple). Si vous avez parcouru plusieurs pages du site ainsi que la page d’accueil, vous pourrez faire de même hors connexion, y compris en ayant éteint votre appareil entre temps !

Vous pouvez utiliser cette fonctionnalité à votre avantage en parcourant les pages ou articles que vous souhaitez lire plus tard. Chargez juste leur page et ils seront accessibles en hors ligne. 

Le cache a néanmoins une limite de taille : s’il manque une page c’est que vous en avez parcouru beaucoup et que celle-ci a été écrasée. Il y a également une limite de temps de 30 jours, au-delà les enregistrements sont supprimés.

N’hésitez pas à « l’installer » sur votre appareil !

Les PWA sont donc installables, c’est ce qui les distingue des sites utilisant les service-worker seuls. Sur Chrome et ses dérivés sur PC (Opéra, Brave, Edge, etc…), une petite icône est présente à cet effet, à droite de la barre d’url. Il suffit de cliquer dessus pour voir le site avec une icône séparée sur la barre des tâches :

Ici, le petit plus à côté de l’étoile.
On obtient une fenêtre avec le site, vous pouvez l’ouvrir depuis Windows comme n’importe quelle application (depuis la barre de recherche).

Pour la désinstaller il suffit d’aller dans les paramètres de cette fenêtre, vous ne pouvez pas le faire depuis Windows (pour l’instant en tout cas).

Ici, en haut à droite de la fenêtre.

Sur mobile ou d’autres navigateurs comme Firefox, cherchez dans le menu quelque chose comme « Ajouter à l’écran d’accueil » ou « installer l’application » et vous aurez le même rendu.

Pourquoi les « Progressives Web Apps » sont probablement une bonne alternative aux applications natives ?

Cette partie est plus subjective, nous pensons que les PWA ont beaucoup de potentiel pour simplifier le développement d’applications multiplateformes. Voici notre point de vue sur les PWA face aux clients lourds sous la forme avantages/inconvénients.

Avantages des PWA face aux applications natives

  • Le défaut principal des applications natives : elles demandent à être téléchargées et installées. Or la capacité de stockage peut être rapidement limitée, surtout sur smartphone… les Messengers qui font 500Mo, non merci ! Le problème ne se pose pas avec les PWA bien conçues. On parle d’une réduction de taille d’un rapport de 1 à 20 ou 25 en moyenne.
  • De la même manière les clients lourds demandent à être mis à jour manuellement (et jusqu’à peu sur Android il était nécessaire de retélécharger l’entièreté de l’application à chaque fois), c’est laborieux et ça consomme de la data, encore une fois gênant, surtout sur mobile ! Vous l’aurez compris les PWA sont majoritairement orientées mobile first. En parallèle ce système de mise à jour peut gêner les développements, les utilisateurs choisissant de garder une ancienne version (problématiques de rétrocompatibilité).
  • Les applications natives posent de nombreux problèmes pour les développeurs et/ou les entreprises qui les créent, puisqu’il faut quasiment les développer en autant de fois qu’il y a de systèmes d’exploitation (Android, iOS, Windows, Mac, ChromeOS, etc…). C’est ici le gros avantage du Web sur le reste, au niveau technique, d’autant plus que la tendance est au remplacement justement à cause de ces contraintes économiques.

Quelques inconvénients des PWA

  • Les PWA peuvent fonctionner en hors ligne mais restent plutôt orientées sur un mode connecté (cette innovation vient du Web, ce n’est pas pour rien). Il faut s’y être connecté au moins une fois pour que le mode hors-ligne fonctionne. Cela peut être une limite à l’installation depuis un « store », mais il faut également être connecté pour télécharger une application donc en soi rien de vraiment problématique. En revanche, d’un point de vue développeur il faut posséder un serveur pour la rendre accessible, alors qu’une application mobile n’a pas cette contrainte.
  • Elles ne sont pas encore entièrement implémentées comme il faut d’un point de vue des API natives (les accès hardware), surtout sur les navigateurs autres que Chrome et ses dérivés. Pour l’instant, il est encore un peu risqué pour une entreprise de se lancer sur une PWA en souhaitant toutes les fonctionnalités d’une application native. Mais dans un futur assez proche cela ne devrait plus être le cas et le problème ne se pose que si l’on souhaite faire appel à des fonctionnalités spécifiques (téléphonie, NFC notamment). Il faut garder en tête que cette technologie est encore en partie expérimentale. Dans notre cas, il nous a fallu participer à la librairie next-pwa pour l’implémenter.
  • Côté performances, il est évident que rien ne vaut une application native. Mais rares sont les cas d’usage sur mobile qui requièrent autant de performances au point que ça pose un réel problème.

En conclusion

Depuis quelques années, on a constaté l’apparition d’outils éditeurs de texte en ligne, à travers Google drive d’abord, puis avec la suite Office, elle aussi entièrement disponible en ligne (à travers Office 365). En plus d’être accessibles très rapidement sans demander d’installation spécifique, ils sont gratuits et déjà en train de tuer la suite office classique. Chez Agaetis tout passe maintenant par ces outils sur le Web ! Signe de plus que les PWA sont des concurrents sérieux aux applications natives, notamment grâce au fonctionnement hors-ligne, maintenant possible.

Dernier argument en leur faveur, depuis mai 2019 environ, il est possible d’ajouter une PWA sur le Google Store après quelques manipulations assez simples, d’ailleurs Google priorise les PWA sur ChromeOS face aux applications Android depuis quelque temps. De même sur l’Apple Store (après des manipulations un peu plus complexes) et c’est sur le Store Microsoft depuis quelque temps déjà (pour Windows 10). Et d’ailleurs depuis le début de cette année, Bing, le moteur de recherche de Microsoft, indexe tout seul les PWA pour pouvoir les ajouter automatiquement dans leur store dans un futur proche. Que demander de plus ?

Alors qu’en pensez-vous ? N’hésitez pas à nous donner votre avis !

Investisseurs, entrepreneurs, comment sécuriser votre levée de fonds ?

Investir dans un projet innovant nécessite d’être bien accompagné pour créer les meilleures conditions de réussite.

Chaque investisseur a besoin d’être éclairé et conforté quant à la viabilité de ses décisions. Notre offre de sécurisation des investissements pour les projets novateurs permettra de vous sécuriser dans votre prise de position.

Nicolas Roux, Directeur général, partage sa vision d’une démarche vous permettant de prendre les bonnes décisions et de pérenniser vos choix face au marché actuel.

En quelques mots, qu’est-ce que l’offre de “sécurisation des investissements” proposée par Agaetis ? 

Les sciences informatiques (technologies, data, IA, IoT, …) sont au cœur des projets innovants, tous secteurs confondus. Ce sont des activités complexes, tant sur l’aspect technique que humain, soumises à des évolutions très rapides et qui représentent une part importante des capitaux engagés.

Notre offre a été spécialement créée pour aider les investisseurs et les porteurs de projets à améliorer la partie technique, informatique et scientifique au moment de la levée de fonds. Elle permet d’évaluer les risques, les opportunités, d’établir le plan d’amélioration et de mettre en œuvre nos préconisations pour accélérer le “time to market”.

A qui s’adresse cette offre ? 

Cette offre s’adresse aux différentes parties prenantes lors d’une levée de fonds : porteurs de projets, leveurs de fonds ou investisseurs.

Les porteurs de projets et les leveurs de fonds ont besoin de se préparer au “due diligence” (ndlr la due diligence est une vérification pré-transaction), les investisseurs ont également besoin d’évaluer la pertinence des technologies choisies avec le plan d’investissement et de suivre chaque phase du projet.

Quels sont les objectifs de cette offre ? 

L’objectif est de réunir les conditions de réussite du projet sur le volet technologique en répondant aux questions suivantes :

  • Est-ce que la technologie permet de créer un avantage concurrentiel ?
  • Est-ce que des technologies alternatives permettraient d’accélérer le time to market ?
  • Est-ce que les investissements et les besoins en R&D ont bien été évalués ?
  • Est-ce que les opportunités et les risques ont bien été identifiés ?
  • Est-ce que les niveaux de maturité des technologies sont compatibles avec les objectifs du projet ?
  • Est-ce que l’équipe est organisée pour assurer le déploiement et maintenir efficacement la solution ?

Qu’est-ce que Agaetis apporte de nouveau dans ce domaine ? 

L’offre se différencie sur 2 axes majeurs. Le premier est une approche à 360° où l’on challenge les volets technologique, que ce soit sur le plan technique, organisationnel et méthodologique du projet.

Le deuxième axe est orienté sur la direction informatique et technique du projet (la gouvernance, la gestion long terme des compétences, le coaching) et stratégique (les contextes de marché et de concurrence).

Quels sont les périmètres de l’analyse de risques ? 

Notre étude porte sur les thèmes suivants :

  • La valeur de l’innovation technologique et la pression concurrentielle
  • Les choix technologiques et leur maturité, la robustesse et l’évolutivité de la solution, la capacité à passer à l’échelle, l’évaluation du coût pour industrialiser la solution
  • Le respect des exigences en cybersécurité
  • Les besoins en R&D pour aller jusqu’à la mise sur le marché
  • La gestion des compétences et la stratégie de sous-traitance / partenariat
  • L’organisation de l’équipe impliquée sur le projet
  • La gestion du portefeuille projet, les méthodologies et les bonnes pratiques

Quelles sont les pièges du développement d’un projet d’innovation numérique ? 

Ils sont nombreux, le premier étant de tomber amoureux de son projet ! Pour limiter ces risques, il faut confronter la solution au terrain. Des méthodes comme le lean-startup ou encore le service design aident à adopter de bons réflexes.

On observe également une sous-estimation des besoins en développement pour aller jusqu’à la mise sur le marché : l’IT comme support aux activités internes, la sécurité, l’interopérabilité, la robustesse, la dette technique … et parfois, certaines solutions ne peuvent pas passer du mode prototype à une solution industrielle sans une refonte complète.

La constitution de l’équipe technique est un facteur de réussite important, il faut évaluer sa capacité à grossir rapidement, à gérer le projet jusqu’à son terme.

Pour terminer, pourquoi faire appel à Agaetis pour accompagner les investisseurs ? 

Nous avons une double culture : celle du conseil pour accompagner à la réalisation et une culture de faiseur où nous intervenons nous mêmes dans le développement. Nous avons une équipe pluridisciplinaire en termes d’expertises et d’expériences. Agaetis s’est construit en associant des expertises issues de différents horizons : start-up, PME, académique, grands groupes, ESN et cabinets de conseil. 

Nous sommes impliqués fréquemment sur des projets associant les laboratoires de recherche publique et les sociétés privées. Les profils de nos collaborateurs sont à l’image des exigences de l’innovation, créatif et pragmatique. Nous baignons dans un écosystème de R&D stimulant.

Nous partageons tous la même volonté de contribuer aux succès des innovations qui constitueront le monde de demain.

L’ENE et Agaetis vous accompagnent dans vos projets !

Vous êtes un industriel d’Auvergne Rhône Alpes et vous souhaitez être accompagné dans vos projets de modernisation et de numérisation de votre production ?

Agaetis a été référencé pour la Région Auvergne Rhône Alpes afin de vous accompagner dans le développement de solutions digitales autour des IoT, systèmes connectés, mais aussi, dans la réalisation de la cartographie de votre SI et la valorisation de vos données de production.

Ce référencement vous permet de bénéficier d’un co-financement lié aux coûts des prestations de conseil, des preuves de concepts et d’études, à hauteur de 50 % pour un accompagnement plafonné à 32 000 € par entreprise (subvention plafonnée à 16 000 €).

Les objectifs de nos interventions :

  • Améliorer le pilotage, la fiabilité et la performance globale de la production grâce à l’exploitation des données process et procédés
  • Anticiper les dysfonctionnements et les pannes.
  • Baisser les couts de non-qualité et améliorer le ROI.
  • Sécuriser vos accès et les informations de votre entreprise.

La cybersécurité et les établissements de santé

Les questions autour de la sécurité des systèmes d’information ont toujours été importantes mais depuis la crise sanitaire du COVID-19, elles prennent une tout autre dimension. 

Les établissements de santé sont en première ligne face aux cybers attaques. Mais pour quelles raisons et quelles sont les solutions qu’ils peuvent mettre en place pour assurer la pérennité de leur SI et de leur activité ? Cédric Lamouche, consultant en cyber défense chez Agaetis répond aux questions que vous pouvez vous poser.

Pour quelles raisons les établissements de santé se retrouvent-ils obligés de faire évoluer leur SI ? Quels sont les buts de toutes ces évolutions ? 

Il y a plusieurs raisons à une évolution du SI, les nouvelles réglementations sur la protection des données, la sécurisation des données de santé, des usages de plus en plus informatisés, des nouvelles technologies intégrées dans le traitement et la prise en charge des patients. Le SI doit perpétuellement évoluer afin de s’assurer d’être en capacité de traiter les nouvelles informations tout en gardant des pré requis au niveau sécurité.

Quel est le rôle du SI pour un établissement de santé ? 

Le SI doit permettre d’assurer l’activité de l’établissement pour cela il doit répondre à des exigences de sécurité, de disponibilité et de traçabilité.

Pourquoi les “cyber malveillants” attaquent-ils les SI des établissements de santé ? 

Les SI de santé sont composés de vastes infrastructures avec de multiples accès où la sécurité est un réel enjeu mais avec un périmètre difficile à couvrir. Ces attaques ont souvent un but lucratif et sont loin des préoccupations éthique. 

La crise sanitaire du Covid a forcé certaines structures à ouvrir leur SI pour permettre une continuité d’activité. Elles se sont exposées au monde extérieur avec une politique de sécurité non adaptée pour se prémunir de cyber attaque. Ces structures deviennent alors des cibles fragiles et parfaites pour mener ce genre d’actions en vue de compromettre les infrastructures et de rendre inopérant le SI.

Ces deux derniers mois, une cyberattaque visant les systèmes informatiques du secteur de la santé a eu lieu tous les trois jours dans le monde.

Europe 1 (2020, 26 mai).

Une fois le système attaqué, sur quoi l’établissement de santé peut-il compter pour s’en sortir ? 

Une politique de sauvegarde est essentielle pour retrouver rapidement son SI. Cette politique implique une prise en charge complète du SI avec des exigences de stockage afin d’assurer la disponibilité du support de sauvegarde et de son exploitabilité.

Quel est le rôle d’une PSSI (Politique de Sécurité des Systèmes d’Information) et comment se compose-t-elle ? 

Une PSSI régit les exigences de sécurité pour le SI. Elle doit couvrir l’ensemble du SI et définir des mesures de sécurité pour protéger les éléments, les actifs les plus importants pour l’établissement. Elle doit être unique et correspondre aux attentes en sécurité de l’établissement, elle est construite autour d’une analyse des risques qui définit les exigences à mettre en œuvre pour assurer une gestion des cyber risques.

Quels sont les autres solutions à mettre en place pour protéger son SI ? 

Une fois la PSSI définie avec des exigences formulées il est nécessaire de mettre en place des solutions techniques pour couvrir les exigences et de pouvoir mesurer les niveaux de sécurité suite aux incidents et changements sur le SI.

Un plan de défense est aujourd’hui nécessaire pour assurer un bon niveau de résilience. Il doit être capable de répondre aux besoins de surveillance, de détections et de gestion des incidents. Il se construit pas à pas en fonction des priorités définies dans l’analyse de risques du SI.

Aujourd’hui, Agaetis accompagne ses clients dans une stratégie de défense de son SI. Nous nous appuyons sur des méthodologies reconnues et des approches de défense basées sur des scénarios d’attaques réelles. Notre savoir faire s’adapte aussi bien aux petites, qu’aux grandes structures en prenant en compte différents objectifs :  financiers, humains, organisationnels. 

Agaetis à Volcamp !

La participation d’Agaetis à Volcamp se précise, on espère que vous avez aussi hâte que nous et que vous avez bien noté les dates ! Au cas où, voici un petit rappel : rendez-vous le 15 et 16 Octobre au Hall 32 à Clermont-Ferrand pour rencontrer des passionnés de la tech et échanger avec eux dans le cadre de différents types d’interventions : Rex, Conf, Workshop, Lightning. 

Parmi les 191 propositions soumises au CFP ce sont 44 talks qui ont été sélectionnés dont deux sujets de Agaetis ! 🎉

Nous sommes très fiers de pouvoir intervenir lors de cette toute première édition ! Car en plus de nous retrouver sur notre stand, plusieurs membres de l’équipe vont pouvoir vous présenter des sujets qui nous tiennent à cœur via deux formats différents. 

Voici donc en quelques lignes les sujets de leurs interventions (juste un petit aperçu, on vous garde quelques surprises 😉).

Un premier sujet porté par François Travais, accompagné de Franck Marchand, deux de nos architectes, aura pour sujet un retour d’expérience sur ce qu’ils ont appris du CQRS au travers de différents projets et expérimentations : quand et pourquoi implémenter une saga ; comment implémenter CQRS/ES avec Kafka et en quoi le CQRS favorise le KISS (Keep It Simple Stupid).

Force est de constater que le nombre de projets impliquant Kafka et de l’event sourcing grandit de façon exponentielle dans les entreprises sous la pression de la data science, du besoin d’audit et de l’agilité. Il est alors souvent difficile de s’y retrouver dans la multiplication des événements supportés par des micro services et de comprendre les enchaînements entre ces événements. CQRS à la rescousse ! 

Dans un second temps Blandine Rondel, développeuse Front chez Agaetis, interviendra lors d’un lightning talk, le sujet : le choix de GatsbyJS, une solution open-source, plus simple, plus légère, plus rapide et plus sécurisée ; idéale pour créer un site moderne ! 

Nous sommes impatients de pouvoir échanger avec vous durant ces deux jours et de faire rayonner nos savoir-faire. On vous attend donc très nombreux, ça va être volcanique ! 🌋😉

Pour réserver vos places et consulter le programme, rendez-vous sur le site de l’événement !

Statisticien et data scientist, deux métiers à ne pas confondre

La synonymie n’existe pas, et c’est peut-être bien là l’information fondamentale de cet article. Nous nous construisons avec l’idée que deux mots distincts peuvent avoir le même sens. Nous sommes régulièrement encouragés à éviter les répétitions par tous les moyens, quitte à utiliser un mot qui n’exprime pas tout à fait notre pensée. Nombreux sont pourtant les universitaires à répéter inlassablement que la langue française est riche et complexe, et qu’il serait absurde de créer deux mots différents ayant exactement le même sens.

Cet article a pour objectif d’expliquer pourquoi les métiers de data scientist et de statisticien ne peuvent pas être confondus ou considérés comme identiques. On parle donc de comparer un mot de la langue française et… un anglicisme. Le problème avec cette dernière catégorie, c’est qu’on se croit vite tout permis. Quand on sait en plus qu’il s’agit d’un anglicisme dont le sens est en constante évolution, on a envie de jeter le stylo (ou le clavier) et d’abandonner face à la difficulté de la tâche. Il est pourtant primordial de comprendre pourquoi le terme de data scientist a émergé et en quoi ce métier diffère des autres métiers existants, en particulier celui de statisticien.

Nous ne chercherons pas ici à comparer le champ des statistiques avec celui de la data science. Cette précision est importante car la data science n’est pas composée exclusivement de data scientists. On y trouve pêle-mêle des data engineers, des machine learning engineers, des data analysts, des products owners et même des statisticiens. C’est à s’y perdre n’est-ce pas ? On ne cherche pas non plus à comparer des outils de machine learning avec des outils statistiques. Non, il s’agit bien de traiter des différences entre deux métiers.

La première des différences est évidente : l’un de ces métiers est beaucoup plus ancien que l’autre. Les premiers statisticiens (1) sont apparus durant le XVIIIème siècle (Thomas Bayes pour n’en citer qu’un), avec une réelle émergence de la discipline le siècle suivant. Les termes de data science et data scientist ne sont utilisés que beaucoup plus tardivement à la fin du XXème siècle, en 1987 (2).

Une autre différence majeure est que les compétences de recherche sont indispensables pour exercer le métier de data scientist. La première raison à cela est la diversité et la constante augmentation du nombre d’outils. Un data scientist doit être en perpétuelle montée en compétences tout en maintenant une routine de veille sur toutes les innovations du domaine. Cela est en tout point comparable à la capacité d’un chercheur à effectuer l’état de l’art de son champ de recherche à tout moment. La seconde raison justifiant la nécessité de ces compétences est la structuration même des missions des data scientists. Ces dernières peuvent démarrer à un stade où le bénéficiaire n’a pas encore défini précisément son besoin ou que sa formulation n’est pas en adéquation avec les outils disponibles. Dire : “J’ai besoin de simuler l’ensemble de la société humaine à la maille de l’être humain” n’est pas un besoin en adéquation avec les possibilités de notre époque. C’est au data scientist d’accompagner ce dernier pour identifier les progressions possibles à l’aide des différentes sources de données voire parfois d’identifier de nouvelles sources de données que l’interlocuteur n’avait pas identifiées. Tout ce travail préliminaire est par nature absent du métier de statisticien dont le travail est d’appliquer des outils de statistiques à un problème cadré et bien défini.

Les outils du statisticien – le logiciel R étant l’un des plus connus – n’en restent pas moins inclus dans ceux du data scientist, qui doit par conséquent avoir des compétences en statistiques. La question qui vient immédiatement est celle de la nature des autres outils du data scientist. Ces derniers n’émergent pas directement du champ des statistiques mais de la théorie de l’apprentissage statistique. Vous l’aurez compris, ce sont ceux que nous regroupons habituellement dans le champ du machine learning. À la différence des outils du statisticien, les outils de machine learning ont pour objectif d’entraîner un algorithme pour prédire de futurs résultats (3), sans nécessairement que les étapes de calcul soient interprétables. Cette approche ayant été développée conjointement avec l’augmentation de la puissance de calcul informatique, aucun de ces outils ne peut être utilisé autrement qu’avec un ordinateur.

Outils statistiquesOutils de machine learning
Non prédictif (inférence statistique)Prédictif
Étapes lisiblesÉtapes pas nécessairement lisibles
Lisse les données du passéÉchantillons train/test (+cross validation)
Utilisation de l’informatique optionnelUtilisation de l’informatique indispensable

Une dernière grande différence entre le métier de data scientist et celui de statisticien est leur caractère pluridisciplinaire, beaucoup plus développé dans le premier cas que dans le second. Il est en effet requis pour un data scientist d’avoir une bonne connaissance d’un ou plusieurs champs disciplinaires scientifiques (physique, chimie, biologie…). Il est même de plus en plus fréquent d’étendre cette recherche de pluridisciplinarité au-delà des sciences dites “dures”, notamment du fait de l’émergence des systèmes complexes ou encore de l’éconophysique, pour n’en citer que deux. C’est d’ailleurs cette différence qui motive les entreprises à recruter des data scientists dans des domaines plus variés que le simple domaine des mathématiques ou de l’informatique.

Nous avons par cet article voulu évoquer brièvement les différences les plus importantes entre les deux métiers. Cela ne nous a pas empêché pour autant de faire ressortir les points communs qui les relient et de mettre en valeur le fait que le métier de data scientist ne pourrait exister sans l’émergence quelques siècles plus tôt du domaine des statistiques ou plus récemment de la forte augmentation de la puissance de calcul.

Gardons également à l’esprit que la Data Science tout entière est en perpétuelle évolution et qu’aucun consensus général n’existe sur sa définition. La réponse sera en effet différente que vous vous placiez dans un grand groupe ou une petite start up ou bien encore que vous vous attachiez plus à la sémantique qu’aux considérations des diverses personnes autour de vous.

(1) : Bien que l’on pourrait dater la première apparition des statistiques à l’époque des mathématiques précolombiennes, nous n’évoquerons ici que les mathématiques modernes (qui correspond au réel avènement du champ des statistiques mathématiques). (retour)

(2) : Data Science and Its Applications, préface, Academic Press, 1995.pdf (retour)

(3) : Il s’agit ici d’un constat global. Il existe en effet des algorithmes à la frontière entre statistique et machine learning, comme les algorithmes de clustering. (retour)

Volcamp is coming !

La planète Agaetis bouillonne d’excitation à l’annonce de la future conférence tech de Clermont-Ferrand. Volcamp est là ! 🎉 Enfin un évènement ambitieux qui permettra aux techs auvergnats de montrer de quoi ils sont capables. L’objectif est de créer une synergie entre les acteurs IT du bassin clermontois tout en faisant la promotion des savoir-faire technologiques et de la beauté du patrimoine local.

« Ici à Clermont, on sait aussi parler de la tech et on a de beaux projets pour le démontrer. »

Chez Agaetis, nous avons tous hâte d’y participer et de démontrer cette passion de la technologie qui nous anime au quotidien.

Les 15 et 16 Octobre prochain au Hall 32 de Clermont-Ferrand, se tiendra la première édition de Volcamp qu’il ne faudra manquer sous aucun prétexte. Marquez le dès à présent dans votre agenda ! Ce sera une formidable opportunité de rencontrer des échauffés de la tech et de parler des derniers frameworks à la mode, des nouveautés Big Data et IA et de ce qui se fait de mieux en terme d’architecture, d’orchestration et de sécurité.

La conférence accueillera une trentaine de speakers dont des têtes d’affiche nationales, il y aura également de la place pour de toutes nouvelles pépites.

Agaetis ne pouvait pas passer à côté de l’occasion et s’est donc engagée en tant que sponsor de l’événement et rejoint ainsi un lineup impressionnant d’entreprises, fleurons du savoir-faire auvergnat. Vous pourrez ainsi venir nous rencontrer sur notre stand.

Et pour l’organisation d’un tel évènement, nous pouvons compter sur une toute nouvelle équipe de choc : l’association “Geek & Terroir”. Une bande de passionnés dont plusieurs membres de Agaetis font partie. Merci à vous tous (un peu en avance) pour votre engagement et votre énergie. Ça va être volcanique 😉🌋

Le programme des deux jours est disponible sur le site de l’évènement !

Agaetis au Jam des Volcans

Du 25 au 27 janvier 2019 a eu lieu la première édition clermontoise du Global Game Jam, événement planétaire décliné chaque année en plus de 800 lieux à travers le monde. Le principe ? Sur un week-end, les concurrents doivent créer un jeu vidéo. Avec toutes sortes d’outils, de profils et de compétences, chaque équipe fait bouillonner ses idées, imagine, conçoit et développe. Les idées fusent, les jeux prennent forme.

Il faut imaginer une grande réunion à l’ONU. Sur l’écran qui fait face à la salle, l’image de l’orateur est coupée par celle d’un extraterrestre en tenue de chantier. Il annonce que la planète doit être évacuée sur le champ : elle sera bientôt détruite pour faire passer une autoroute intergalactique ! Un général apparaît sur le même écran et montre des vidéos en direct d’objets volants, plutôt mignons, mais fonçant sur la Terre. Dans l’assemblée sidérée, une personne de l’assistance s’écrie : « il faut protéger notre chez nous, déployez le S4, le Super Secret Space Shield ! »

Voici comment démarre le scénario écrit par l’équipe d’Agaetis pour le Game Jam 2019, inspiré de H2G2, le Guide du voyageur galactique. Cette année, l’événement a rassemblé une soixantaine de participants répartis en une dizaine d’équipes. Tous, à Clermont comme ailleurs, doivent créer un jeu autour du thème What Home means to you. Partenaire de la Jam des Volcans, Agaetis a constitué son équipe naturellement, en fonction des gens qui souhaitaient participer. Elle comprend Alexandre Fiale, Arnaud Ribeyrotte, Julien Usson et Simon Dujardin, tous développeurs full stack, ainsi que Bertrand Pelletier, data scientist, et Pierrick Revol, coordinateur.

Baptême du feu

Tous sont passionnés de jeux vidéos, mais aucun ne s’était vraiment frotté à la création, sauf Bertrand qui travaille sur des projets personnels. « J’ai toujours souhaité mélanger jeux vidéos et data science. En arrivant chez Agaetis, je me suis rendu compte qu’ici, il y a tous les talents techniques pour faire un jeu. Le jeu vidéo c’est un problème qui comprend des problèmes de codes, de graphisme, de scénario, de musique, de cohésion globale… L’idée était de voir ce qu’on pouvait faire en deux jours sur un sujet qu’on ne maîtrisait pas. »

Si Agaetis a participé, c’est avant tout pour la qualité du challenge proposé par le Game Jam. « On est des joueurs acharnés, des codeurs et des techniciens » ajoute Pierrick. « Mais on a toujours besoin de monter en compétence, même sur ce qui n’est pas forcément dans nos coeurs de métiers. Notre travail chez Agaetis consiste en partie à restituer ce que disent des données. Et typiquement, un jeu vidéo, c’est de la visualisation d’informations. On s’aperçoit qu’on doit aller chercher cette capacité dans les moteurs graphiques, et de plus en plus, ces technologies entrent dans nos métiers. »

Outre le challenge de créer un jeu vidéo, l’idée était aussi de perfectionner le travail en équipe. Mieux connaître les autres a été la motivation première d’Alexandre, « faire autre chose avec les collègues, passer du bon temps sur un projet commun. »

Vendredi soir

Le week-end se déroule à l’ISIMA d’Aubière. Ambiance Hackathon, tablées couvertes d’ordinateurs, de câbles, de post-it et de tasses à café, avec baby-foot et bien sûr, buffet généreux pour motiver les troupes. Le Game Jam des Volcans débute avec un briefing suivi de séances de jeu grandeur nature et d’un speed dating pour briser la glace entre les participants, même si beaucoup se connaissent déjà.

C’est ensuite seulement que le concours commence : idées mises sur la table, définition de la forme… Le jeu de la team Agaetis sera simple et sympa, en 2D façon Pixel art, pour être – autant que possible – livrable et jouable pour la fin du Game Jam.

En amont, les six partenaires ont échangé sur leurs envies créatives et listé les outils utiles pour le développement, le prototypage ou encore la création de musique. Le choix s’est porté sur Unity, capable de créer un jeu de A à Z. « Il fait de la 3D et peut servir à plein d’autres choses, on s’en sert dans l’industrie » précise Bertrand. « Unity est très complexe mais il permet une grosse montée en compétence » ajoute Arnaud. « Le but est ensuite de peaufiner notre savoir sur cet outil qui possède une grande communauté et qui est amené à évoluer ». Julien raconte s’être un peu préparé en regardant des tutoriels sur Youtube, « ça m’a aidé ! Unity a une logique très différente du développement web, il faut un peu retourner son cerveau. » Pour le prototypage, l’équipe a misé sur Construct, qui permet de faire l’ébauche du jeu, de tester les éléments de gameplay, de créer le storyboard.

Samedi matin

La nuit porte conseil. La narration est déjà bien ficelée. Face aux vagues d’attaques d’aliens, l’idée principale du jeu est de déployer un système de défense ou d’attaque autour de la Terre sous la forme d’un bouclier qui tourne autour de la planète. L’action est enrichie par un système de boss avec un QTE (Quick Time Event), plus ou moins difficile selon les performances du joueur sur la première phase.

« Le plus difficile dans ce genre de défi, c’est qu’on va vite imaginer des choses complètement farfelues sans aboutir à quoi que ce soit » commence Pierrick, dont la principale mission a été de définir la trame narrative du jeu, puis d’aider l’équipe à s’organiser. « Le plus important, c’est d’arriver à créer des moments où on se pose ensemble, on regarde où on en est pour se concentrer sur l’essentiel. »

Durant le Game Jam, Alexandre s’est penché sur les algorithmes qui définissent les attaques ennemies, la correction de bugs et l’ajout de sons. Arnaud a géré l’esthétique du jeu et son fonctionnement. En plus d’un peu de développement, Julien a créé la musique sur le logiciel Bosca Ceoil, les menus et la partie QTE. Simon s’est concentré sur le graphisme et les sprites (éléments graphiques qui se déplacent sur l’écran) via Aseprite. Enfin, Bertrand a assuré le prototypage afin de déterminer la direction pour le gameplay.

À midi, le prototype fonctionne, les développeurs commencent à coder, les autres se concentrent sur les sprites et la musique. La difficulté : Unity fourmille de subtilités. Pour éviter de s’embourber dans un codage sans fin, le groupe choisit de se concentrer sur l’histoire, le graphisme et une base de jeu simplifiée, et de bien distinguer dans le jeu la partie défense de la base de la partie boss et QTE.

Dimanche

C’est la phase du projet où le code s’impose pour corriger les bugs. Malgré tout, les choses avancent grâce à la simplicité du jeu et aux décisions prises. « J’ai vraiment découvert la compétence des développeurs durant la Jam » confie Bertrand, « ils ont des problématiques que je n’anticipais pas avant, et là je l’ai vécu avec eux. »

Avec un rendu prévu pour 15 heures avant présentation à tous les autres participants, la dernière ligne droite s’avère plus stressée voire électrique. Alexandre évoque un manque de communication nourri par l’urgence. « Il a fallu qu’on pose nos marques, et qu’on garde le bon côté de l’entreprise pour la coordination. »

Délai tenu pour l’équipe d’Agaetis qui parvient à présenter son jeu. Pour Arnaud, le cadrage du début a permis de partir sur une idée viable, sans perte de temps, « et le fait d’avoir une équipe polyvalente a contribué à faire quelque chose de sympa. »

« On a tous des caractères forts, mais on s’est écoutés, on a appris et on a fait ce qu’on a pu » termine Julien. « Je suis fier, vu qu’on était novices : on a fini notre jeu, il est jouable et présentable. C’est mon premier jeu, ce n’est peut-être pas le plus beau ou le plus original mais il est fini et il est fun. »

La Jam des Volcans ne désigne pas de vainqueur, mais le but du week-end est atteint : rencontrer, échanger, et créer l’effervescence. À l’unanimité, tous les membres de l’équipe sont prêts pour renouveler le défi.

Retrouver le jeu sur la page de la Jam et pour jouer à S4, c’est par ici :

12 clés de succès d’un projet Big Data

Les projets Big Data structurants pour les activités à venir de l’entreprise et dépassent donc l’enjeu technique. Il s’agit de mettre en place une démarche globale, transverse à tous les métiers, impliquant une nouvelle organisation, de nouvelles méthodes et des nouveaux outils. Voici, en résumé, quelques points essentiels à prendre compte pour créer les conditions de succès :

Technologie

  1. Prévoir l’intégration de plusieurs technologies à mettre en œuvre : chaque technologie apporte une fonctionnalité spécifique, et il faut souvent en utiliser plusieurs simultanément pour répondre à toutes les demandes (temps réel, analyse, IoT, volumétrie, format de stockage, …)
  2. Considérer que l’architecture doit être évolutive: les technologies évoluent très rapidement ainsi que les besoins, il faut prévoir une architecture offrant une souplesse à l’usage (API gateway, ESB, conteneurisation, …)
  3. Garantir la montée en compétence de tous les métiers techniques (développement, data science, infrastructure, maintenance, …) afin de bien exploiter le monde distribué
  4. Créer un univers de data science avec des outils adaptés à l’exploration (Python, Jupyter, Zeppelin, …)

Data

  1. Mettre en place une gouvernance autour de la data :
    • Garantir la sécurité
    • La qualité
    • La gestion des habilitations
    • Gérer les contrats avec les fournisseurs tierce
  2. Fiabiliser les sources des données : le plus gros coût dans le Big Data est le travail nécessaire pour disposer d’une donnée exploitable. Cela passe par :
    • Le choix des partenaires
    • La vérification de l’intégrité des données issues d’applicatifs internes (ex : ERP, CRM, …)
    • La mise en place d’exigence métrologie pour garantir que l’on mesure les bonnes informations (IoT)
    • Considérer les données brutes comme un patrimoine, la donnée une fois transformée est « corrompue » à jamais
  3. Tenir compte des contraintes de la GDPR dès le départ : répondre aux exigences à posteriori peut être très couteux
  4. Mettre en place une équipe de data scientists en tenant compte des spécialités et de l’expérience des profils

Organisation

  1. Adopter les méthodes et les outils permettant d’offrir une réactivité aux métiers et favoriser l’itération pour affiner les nouveaux produits / services :
    • Mettre en place des approches UX (service design, design thinking, …)
    • Favoriser les développements et déploiements rapides: l’objectif est de passer d’un prototype à une version industrialisée le plus rapidement possible.
    • Mettre en place des équipes pluridisciplinaires, intégrant les métiers, les utilisateurs, les développeurs et les data scientists avec des méthodes comme le BDD (Behavior Driven Development)
  2. Acculturer les métiers à l’innovation et la data: mettre en place des BBL, des ateliers, des formations, des datacamp, challenges internes
  3. Créer de la curiosité et de l’émulation autour des projets : la communication interne est importante pour comprendre ce qui est fait et ce que l’on peut faire avec la data
  4. Réussir les premiers cas : en général, on favorise dans un premier temps des projets permettant un « quick win» sans impact majeur sur l’activité de l’entreprise. Cela permet à la fois d’ajuster l’architecture et de rôder les outils, les méthodes et l’organisation.

Article LinkedIn

Start-ups BtoC : ce qui les freine ?

Réagissez directement sur l’article publié sur LinkedIn par Jérôme Didat

Ce soir, il y a un match de rugby. Je prévois de m’ennuyer devant le jeu des Bleus, sans même parler de gagner ou perdre …

Du coup, je voudrais intéragir pendant le match sur un sujet : « Ce qui freine l’emergence des start-ups BtoC ». Non, pas ce qui pourrait accélérer leur développement (méthodes, éco-système start-up, open innovation, etc) mais bien ce qui leur faire perdre du temps. J’ai listé 11 points : à vos commentaires pour en ajouter voire me dire combien je me suis trompé sur tel ou tel point ! Ce que j’en ferai : certainement vous inviter à co-construire un Skunk (httpss://en.wikipedia.org/wiki/Skunk_Works)

  1. Chercher des financements : faire des VC ses premiers clients, remplir des dossiers de financement, attendre les jurys d’un incubateur …
  2. Ne pas avoir assez de datas pour construire ses services / algorithmes / IA
  3. Devoir construire une architecture IT de développement /production : soit s’en passer au début … et refactoriser ensuite ; soit en construire une et perdre du temps par rapport au service visant les clients
  4. Commencer à tester uniquement après avoir finalisé son produit : surtout dans le cas du BtoC
  5. Se lancer et devoir consommer 50% de ses fonds sur google et Facebook pour rallier des clients
  6. Ne pas avoir les compétences IT / business / métiers réunies au départ
  7. Ne pouvoir recruter que des juniors une fois lancée : par manque de moyens et difficulté à être compétitif avec les grands groupes
  8. Être approchée par des grands groupes pour des accords et partir sur des temps longs de négociation : et du coup perdre énooooormément de temps en réunions et « développement PowerPoint »
  9. Chercher des solutions pour continuer à assumer vie personnelle et entreprenariat
  10. Avoir des prestataires et indépendants disséminés dans Paris et devoir les coordonner

Table Ronde • Transformation des organisations : La fin des managers ?

 “Nous sommes arrivés à un moment clé dans l’histoire du management”

Gary Hamel, Président-fondateur de Strategos, cabinet international de conseil en management.

Cycles de décisions trop longs, lourdeurs bureaucratiques… l’entreprise telle que nous la connaissons serait en train de vivre ses dernières heures. Aujourd’hui, le partage de connaissances et des tâches serait le nouveau terreau des modes d’organisation du travail.

Les entreprises sont-elles prêtes à faire face à cette évolution ?

A l’instar de Michelin, aujourd’hui émergent des groupes qui laissent la liberté aux employés de décider de leur propre mode de fonctionnement. Dès lors on peut se poser plusieurs questions :

  • La hiérarchie pyramidale est-elle un frein à l’innovation ?
  • A-t-on encore besoin des managers ?
  • Faut-il transformer fondamentalement l’architecture des entreprises pour donner la chance aux talents individuels de s’exprimer ?
  • Quelles sont les expérimentations qui marchent ?
  • Le travail en réseau, est-ce l’avenir ?

Plusieurs experts issus de secteurs d’activité différents débattront lors d’une table ronde le 28 juin 2017 au Groupe ESC Clermont.

Avec la participation de :
Samuel Retière, Agile Coach – 16 ans d’expérience Transformation des organisations Speaker Lean & Agile
Luc Dagès, Agile Coach – 28 ans d’expérience Craft IT et transformation digitale Speaker Lean & Agile

Rendez-vous le 28 juin 2017 à 18h30

Entrée Libre

Groupe ESC Clermont

Auditorium Jean-Philippe Genova 4 boulevard Trudaine ∙ 63000 Clermont-Fd

• RENSEIGNEMENTS ET INSCRIPTION •

Contact : Laura Miton
04 73 98 24 27 ∙ laura.miton@esc-clermont.fr

-> Inscription obligatoire par retour de mail

L’innovation, ça marche comment ?

La première étape est d’essayer de détecter de nouveaux cas d’usage pour créer de nouveaux services. Une fois les usages détectés, on crée un écosystème, un terreau capable de faire émerger des pistes ou des idées pour répondre aux enjeux client.

Au sein de cet écosystème, on retrouve des collaborateurs Métiers interne mais aussi des prestataires externes et évidemment une méthodologie, une démarche agile, de l’UX Design. En travaillant l’expérience utilisateur, on crée un MVP (Minimum Viable Product) en un minimum de temps pour qu’on puisse le tester rapidement. Ce n’est qu’au cas où certains services fonctionnent que j’itère !

En somme, dans la conception d’un nouveau produit, dans une démarche d’innovation tout le monde doit comprendre que le produit est un être vivant.

Big Data : IT / MÉTIERS, et si on se parlait ?

Mauvaise(s) synergie(s), projets au long cours, perte de sens et de motivation… Il semblerait que les équipes IT et Métiers ont du mal à s’accorder sur le concept d’innovation. Mettre en place des briques technologiques ne serait donc pas la condition sine qua none au succès des projets Big Data. Pour que ces projets conduisent les organisations sur le chemin du succès, il est temps que l’IT et les Métiers trouvent un espace de jeu afin d’expérimenter ensemble la co-construction.

Notre expert Nicolas Roux, Directeur Agaetis et Directeur Innovation Novencia Group, revient sur les principales raisons de l’échec de la majorité des projets Big Data mais aussi sur les méthodes à mettre en place pour créer des synergies. Entretien.

Selon un analyste de Gartner, 70% des projets Hadoop échouent en raison d’un manque de compétences et d’attentes trop élevées des organisations.

Donc près des 3/4 des projets Big Data Hadoop sont voués à l’échec ?

Il y a deux raisons majeures à l’échec des projets Big Data.

Lorsqu’on évoque l’échec de 3/4 des projets Big Data, on confond souvent ces échecs avec les mauvais retours d’expérience sur les datalake. En rassemblant les données dans une énorme base, en faisant travailler un data scientist sur l’exploitation des données, les entreprises ont cru mettre en œuvre des projets Big Data. Par ailleurs, depuis 2012, le buzz autour du Big Data et l’injonction à l’innovation, ont poussé les entreprises à réduire le concept d’innovation à l’installation de briques technologiques par la DSI.

Jusqu’en 2015, la vision des Big Data était donc trop technophile avec une DSI qui montait des projets avec de gros budgets sans avoir réfléchi à la gouvernance des données ou à quoi allait concrètement servir ces nouvelles technologies. Je compare souvent cette démarche en citant l’exemple de Renault qui s’est amusée à fabriquer un Renault Espace en mettant un moteur de Formule 1. Résultat, la firme au losange disposait d’un véhicule ultra performant dont la réalité économique s’est limitée au buzz.

On est dans la même configuration pour le Big Data. En interne, les DSI ont mis en place des technologies trop complexes et les Métiers ont été incapables de les exploiter. C’est de cette décorrélation qu’est né ce premier constat d’échec.

Le deuxième échec concerne la démarche innovation.

Traditionnellement comment était-elle abordée ? Une entreprise lambda se disait experte sur le marché d’un type de produits, elle investissait en R&D (Recherche et développement) et du coup, naturellement, elle avait le rôle de créateur d’innovation. Aujourd’hui, la tendance c’est de dire « j’ai compris que mon produit n’est qu’une brique et je dois faire en sorte qu’il corresponde à des usages ». La tendance est donc au « customer centric » qui prend en compte les besoins clients dès le départ du projet.

En ce sens, dans l’innovation digitale, on construit un produit vivant. Tous les 6 mois, tous les mois, voire tous les jours dans certains cas, le produit doit être amélioré, doit offrir de nouvelles fonctionnalités. Le dialogue de sourds entre IT et métiers résulte, en dehors de l’aspect technologie, du manque de démarche et de méthodologie générales qui doit être véhiculée par une approche innovation.

Comment identifie t-on un dialogue de sourds ?

Comment on identifie rapidement un dialogue de sourd ? Dès qu’on arrive chez un client et qu’on s’aperçoit, d’une part que, la DSI a investi des sommes énormes sur son SI pour pouvoir mettre en place des briques technos type big data. Et d’autre part, que les Métiers ne comprennent pas la valeur ajoutée et le temps perdu à monter un tel projet. C’est une situation coutumière des grands groupes. On la retrouve plus rarement au sein des nouvelles directions digitales.

Autre cas de figure, un produit a été fabriqué dans une démarche d’innovation. Sauf que le bât blesse quand la DSI s’aperçoit qu’elle n’a pas été consultée et qu’elle met son veto au moment d’industrialiser en estimant que le produit ne correspond en rien à l’architecture cible, ni aux contraintes sécuritaires. Donc, on se retrouve avec un produit construit qui ne correspond à aucune règles internes du SI.

Comment amorcer le dialogue ?

En somme, il manque un espace de jeu entre la DSI et le Métier pour qu’ils expérimentent ensemble. Les DSI traditionnelles doivent comprendre qu’elles ne prennent pas de risques si elles apprennent à fonctionner autrement. A contrario, au sein des start-ups industrialisées comme Vente Privée par exemple, ces problématiques n’existent pas car elles ont une vraie culture du digital et de l’innovation. Elles se sont développées sur ce modèle de co-construction dès le départ.

Réussir un projet Big Data c’est donc une question de mentalités ?

Au niveau des organisations, certains de nos clients sont dans une dynamique transverse et agile, et ont donc atteint un bon niveau de maturité par rapport à ces problématiques. A contrario, certains de nos clients n’ont pas d’approche disprutive par rapport à leur marché.

Concernant l’IT, il faut prendre en compte qu’à l’origine, la DSI est le garant d’un SI fiable, sécuritaire qui doit offrir un SLA (Service Level Agreement) de plus de 99%, et assurer la maintenance en cas de panne. Son rôle est de faire des choix techniques et de garantir la gestion d’un ensemble d’applicatifs qui va permettre à la société de fonctionner au quotidien. Sauf que, c’est antinomique avec les approches d’innovation car, dans une démarche d’innovation on utilise des technologies très récentes et non usitées. Et il est fréquent qu’un DSI refuse de mettre en en place certaines technologies car les éditeurs sont inconnus.

Enfin, coté Métiers, ils s’épuisent et se découragent car chaque projet fait l’objet d’un développement long qui s’étale de 6 mois à un an. Or, dans une démarche d’innovation, un cycle de test ne doit pas dépasser les 4 mois. Au delà, le terme d’innovation est galvaudé.

Donc oui, changer les mentalités, vivre avec son temps, prendre des risques sur de nouvelles technologies, tester, industrialiser tout en préservant la sécurité du système informatique permettrait de mener au succès un projet Big Data.

L’innovation n’est donc pas qu’une question de temps ?

Quand on veut innover, on prend en considération plusieurs facteurs : l’organisation des équipes, les méthodologies et les outils à mettre en œuvre . Quand on veut que ça fonctionne bien on se monte une « feature team », c’est à dire une équipe pluridisciplinaire, de taille réduite, qui va travailler sous un mode collaboratif.

Dans ces équipes, on retrouve des développeurs ultra expérimentés. Ces artisans du code, appelés craftsmans, sont capables de mener un projet de A à Z tout en appliquant de très bonnes pratiques afin que l’applicatif puisse évoluer facilement grâce à des test produit tous les 4 mois. Aujourd’hui, on n’a plus besoin d’une équipe de 20 personnes pour réaliser un produit car les craftsman savent utiliser les bons outils comme la livraison continue par exemple. Grâce à cette méthodologie, on peut réduire les coûts et envisager l’industrialisation au fur et à mesure des succès rencontrés.

La data est-elle la passerelle pour améliorer le dialogue ?

Aujourd’hui la data est un moteur de l’innovation. A partir de son exploitation, on va pouvoir répondre aux problématiques d’un client et de ses usages. L’enjeu, c’est réussir de mettre dans la même pièce IT et Métier pour qu’il discute ensemble d’une bonne exploitation de cette data et de la mise en place de bons outils.

Auparavant, on faisait le choix d’une base de données qui devait répondre à 90% des cas d’usages. Aujourd’hui, tout est différent car avec des feature team, on peut gérer 10 projets différents avec 10 équipes différentes et si ça se trouve dans ces 10 projets, il y aura des briques technos communes à l’ensemble des 10 projets et des briques spécifiques communes à seulement 2 projets. Le dialogue est donc extrêmement important car si tout le monde travaille sur le customer centric la matière première c’est la data. C’est donc le point commun entre l’IT et les Métiers.

Dans des entreprises comme Facebook, on innove par le code, le Métier a une idée, l’IT développe un bout de code.

Doit-on former les collaborateurs ?

Les collaborateurs doivent être formés et coachés sur les méthodologies et les outils. Aujourd’hui on parle beaucoup de coach agile car les entreprises ont besoin de personnes qui sont à la pointe des nouvelles technologies et de leurs utilisations, IoT, applicatif, chatbot, blockchain… La veille technologique et sectorielle doit être très forte et il est nécessaire que le niveau d’acculturation des collaborateurs soit forte. En somme, les collaborateurs doivent être formés sur comment on passe de l’idée à l’applicatif.

Quels sont les avantages que les équipes IT & Métiers peuvent tirer d’une co-construction ?

L’enjeu encore une fois c’est les feature team mais un autre enjeu c’est aussi de décloisonner les équipes et d’impliquer les IT sur la conception de produit. Une équipe pluridisciplinaire est selon moi, un facteur de succès.

Concrètement, un projet big data est souvent lié à un projet innovation c’est pourquoi j’ai insisté sur le concept d’innovation. Car le but ultime, c’est l’expérience utilisateur, c’est comment faire que son organisation soit plus performante, que les collaborateurs soient impliqués, comment faire en sorte que les technologies facilitent le quotidien des collaborateurs sans passer nécessairement par de la formation au logiciel… Aujourd’hui, il faut inverser ce qu’on connait dans l’entreprise. Il faut concevoir des logiciels qui collent aux besoins en interne, des nouveaux produits qui correspondent aux utilisateurs et non l’inverse.

Pour encourager le dialogue, peut-on évoquer le facteur de réduction des coûts ?

L’enjeu pour moi n’est pas là. L’enjeu est d’être disruptif et de véritablement se transformer digitalement.

Chez Agaetis, quelle est votre approche ?

Notre approche c’est de proposer une start-up interne. On n’est pas là pour tout transformer, on est là pour montrer l’exemple. En faisant de l’évangélisation par l’exemple, on co-construit avec le client. Notre objectif est de partir d’un use case. A partir de là, on explique au client comment aller, comment communiquer autour du projet et obtenir l’adhésion de l’ensemble des collaborateurs, y compris ceux qui ne font pas partie du projet. On crée de la curiosité dans l’entreprise et on emporte avec nous toutes les équipes qui attendent du coup, les améliorations.

Agaetis vous accompagne pour mener à bien vos projets !

Agaetis recherche des artisans développeurs

Envie de réellement mettre en pratique les dernières technos « hype » sur des projets innovants et challengeants ?
Chez Agaetis, depuis 10 ans, nous accompagnons nos clients dans leurs projets Big Data et Data Science, de l’idée jusqu’à la mise en production : idéation, lab, architecture, développement, Ops.
Nous recherchons un artisan développeur pour intégrer notre équipe d’experts !
JavaScript, Angular, React, Spring Boot, Node.js, MongoDb, ElasticSearch, Git, intégration continue et bien d’autres seront de la partie.
Même si tu ne maîtrises pas l’intégralité de cette stack, nous t’accompagnerons dans ta montée en compétences.
Intéressé(e) !? Expérimenté(e) ou Junior ?
Viens en discuter avec nous autour d’un café ou contacte-nous via recrutement@agaetis.fr ou au 04 73 35 47 51.
La société
Agaetis est spécialisée dans les analyses de données et les technologies Big Data. Depuis 2007, nos experts accompagnent les grands comptes et les PME dans les projets innovants et stratégiques dont l’exploitation des données est un critère de succès.
Agaetis dispose d’une forte expérience dans le traitement de données d’objets communicants (télématique embarquée sur les véhicules, machines, capteurs, …) et l’exploitation de données scientifiques (agriculture, environnement, industrie).

Partenariat Cloudera

Depuis 2016, Agaetis est partenaire de Cloudera, un acteur majeur du big data.

Grâce aux solutions Cloudera, Agaetis renforce son offre big data pour accompagner ses clients grands comptes. L’éditeur propose une plateforme permettant de traiter, d’analyser des volumes de données importants.

Partenariat Datastax – Cassandra

Depuis 2015, Agaetis est partenaire de Datastax, principal contributeur de Apache Cassandra.
Agaetis utilise Cassandra dans des projets nécessitant le traitement de gros volumes de données en temps réel, tel que la gestion d’objets connectés. Cassandra est reconnue pour sa capacité à enregistrer des données massives, sa haute disponibilité et son intégration avec Apache Spark pour l’analyse de données.
Ce partenariat permet de répondre aux plus grandes exigences techniques (architecture, sécurité, monitoring, …) et opérationnelles (support, formations, …).

Partenariat MongoDB

Depuis début 2015, Agaetis est partenaire MongoDB, leader des bases de données orientée document.
Agaetis a utilisé MongoDB dans de nombreux projets depuis sa sortie en 2009. Cette technologie apporte une grande souplesse dans la gestion de données hétérogènes, une mise en œuvre rapide dans les phases de prototypage et une capacité à gérer des gros volumes de données.
Ce partenariat permet de répondre aux plus grandes exigences techniques (sécurité, sauvegarde, monitoring, …) et opérationnelles (support, formations, …).
MongoDB est utilisé dans des gros projets (Adobe, Amadeus, LinkedIn, eBay, SAP, …) et a été financé à hauteur de 231 M$.

Référence : Gestion et analyse de données de radars de pluie

Création d’une plateforme permettant d’analyser en temps réel les évènements climatiques.

Objectifs

  • Analyser en temps réel l’évolution des lames d’eau

Réalisations

  • Intégration des données issues d’un réseau de radars
  • Intégration et optimisation des algorithmes d’analyse des données
  • Développement de différents outils d’aide à la décision

Secteurs : Environnement, agriculture

Référence : Analyse de données des marchés des céréales

Outils d’analyse des marchés des céréales et matières premières.

Objectifs
Proposer aux acteurs du secteur agricole des outils d’aide à la décision pour le positionnement sur les marchés.
Réalisations

  • Intégration des données financières
  • Implémentation des algorithmes d’analyses

Secteur : Agriculture

Référence : Analyse de données génétiques

Migration des bases de données et des outils d’analyses afin de gérer un volume de données exponentiel.

Objectifs
Mettre en place une solution technique pour analyser des données génétiques dont le volume est en croissance exponentielle (plusieurs milliards aujourd’hui).
Réalisations

  • Migration des données MS-SQL vers une solution NoSQL
  • Migration des algorithmes vers un langage de programmation fonctionnelle
  • Temps de calculs divisé par 200  (traitements passés de 18h à moins de 5 minutes)
  • Division des coûts de l’infrastructure par 8

Secteur : Agriculture

L’avenir de l’industrie est dans le Big Data

Dans une interview accordée à Télérama, l’économiste américain Jeremy Rifkin explique que l’avenir de l’industrie est dans la gestion du Big Data :

Certains s’y mettent, en particulier dans le domaine de l’énergie. Et mieux vaut ne pas trop tarder. Car, comme je l’ai dit aux cinq plus gros groupes énergétiques allemands devant la chancelière Angela Merkel, et aux dirigeants d’EDF : « vous allez changer de métier ».
Quand des millions d’individus produiront leur propre énergie gratuitement et l’échangeront sur Internet, ne comptez pas gagner de l’argent en fabriquant du courant électrique : votre job, ce sera de gérer le Big Data de l’énergie pour faciliter la circulation des flux entre particuliers et entreprises.

Jeremy Rifkin, interview accordée à Télérama

Exemple de requête géolocalisée avec Spring Data Elasticsearch

 Elasticsearch maintenant supporté par Spring Data

L’un des nouveaux modules intégré dans la nouvelle version de Spring Data est spring-data-elasticsearch. Il permet, comme son nom l’indique, de requêter un serveur/cluster Elasticsearch. Franck de Agaetis est un contributeur du projet.
Dans la liste des fonctionnalités apportées par ce projet communautaire de Spring Data, il existe celle de faire des requêtes géolocalisées. Pour être plus clair, il est possible de retrouver, par exemple, toutes les personnes dont le nom contient « Blaise » et qui habitent à Clermont-Ferrand.

Plusieurs saveurs de requête : « Criteria » ou « Repository »

Il existe plusieurs manières de faire une requête dans le monde de Spring Data :

  • Utilisation des Criteria, où l’on construit la requête gâce à une API « fluent ».
  • Un repository où le nom des méthodes et leurs paramètres permettent de construire la requête.

Spring Data est très sélectif : il faut respecter ses « Criteria »

Voici un exemple qui permet d’illustrer la manière de construire des requêtes Spring Data Elasticsearch avec les « Criteria » :
Dans le cas de cet exemple, les données sont des noms de personnes associés à un identifiant et des coordonnées géographiques.
Voici comment on indexe ces données :

...
List<IndexQuery> indexQueries = new ArrayList<IndexQuery>();

// Blaise PASCAL in Clermont-Ferrand
indexQueries.add(new AuthorMarkerEntityBuilder("1")
    .name("Blaise PASCAL")
    .location(45.7806d, 3.0875d)
    .buildIndex());

// and Isaac NEWTON in London
indexQueries.add(new AuthorMarkerEntityBuilder("2")
    .name("Isaac NEWTON")
    .location(51.5171d, 0.1062d)
    .buildIndex());

esTemplate.bulkIndex(indexQueries);
...

Voici la classe AuthorMarkerEntity qui permet de transformer et de récupérer les résultats de requête (marshal/unmarshal).

@Document(indexName = "test-geo-index", type = "geo-class-point-type", indexStoreType = "memory", shards = 1, replicas = 0, refreshInterval = "-1")
public class AuthorMarkerEntity {
    @Id
    private String id;
    private String name;
    private GeoPoint location;

    private AuthorMarkerEntity() { }

    public AuthorMarkerEntity(String id) {
        this.id = id;
    }

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public GeoPoint getLocation() {
        return location;
    }

    public void setLocation(GeoPoint location) {
        this.location = location;
    }
}

Ensuite, un exemple de requête pour trouver toutes les personnes qui vivent à moins de 20 kilomètres de Clermont-Ferrand :

CriteriaQuery criteriaQuery = new CriteriaQuery(
    new Criteria("location")
        .within(new GeoPoint(45.7806d, 3.0875d), "20km")
);
List<AuthorMarkerEntity> result = esTemplate.queryForList(criteriaQuery, AuthorMarkerEntity.class);

Cela devrait renvoyer uniquement « Blaise PASCAL ».
Il est aussi possible de combiner les critères de recherche. Par exemple : la requête ci-dessous retrouve toutes les personnes dont le nom contient « Isaac » ET qui habitent à moins de 20 kilomètres de Londres.

CriteriaQuery criteriaQuery = new CriteriaQuery(
    new Criteria("name")
        .is("Isaac")
        .and("location")
        .within(new GeoPoint(51.5171d, 0.1062d), "20km")
);
List<AuthorMarkerEntity> result = esTemplate.queryForList(criteriaQuery, AuthorMarkerEntity.class);

Des noms de méthode qui définissent une requête : pas bête la bête !

Spring Data peut utiliser le nom d’une méthode et la valeur des paramètres fournis pour construire une requête.
Pour commencer voici un extrait de la classe SampleEntity :

@Document(indexName = "test-index", type = "test-type", indexStoreType = "memory", shards = 1, replicas = 0, refreshInterval = "-1")
public class SampleEntity {
    ...
    @Id
    private String id;
    ...
    private GeoPoint location;

    public GeoPoint getLocation() {
        return location;
    }

    public void setLocation(GeoPoint location) {
        this.location = location;
    }
    ...
}

Voici un extrait du « repository » qui pourrait être utilisé pour requêter des « SampleEntity ».

public interface SampleCustomMethodRepository extends ElasticsearchRepository<SampleEntity, String> {
    Page<SampleEntity> findByLocationWithin(GeoPoint point, String distance, Pageable pageable);
}

Ainsi quand la méthode « findByLocationWithin » sera appelée, une requête pour retrouver tous les « SampleEntity » autour des coordonnées passées en argument, sera construite et exécutée.
Voici deux écritures équivalentes :

CriteriaQuery criteriaQuery = new CriteriaQuery(
    new Criteria("location")
        .within(new GeoPoint(45.7806d, 3.0875d), "20km")
);
List<AuthorMarkerEntity> result = esTemplate.queryForList(criteriaQuery, AuthorMarkerEntity.class);
Page<SampleEntity> page = repository.findByLocationWithin(new GeoPoint(45.7806d, 3.0875d), "20km", new PageRequest(0, 10));

 Pour plus d’informations sur le projet : httpss://github.com/spring-projects/spring-data-elasticsearch

Contribution à Spring Data Elasticsearch

Des sources de données hétérogènes : une problématique bien connue

Beaucoup de projets nécessitent l’utilisation et la transformation de données hétérogènes. Si les outils utilisés ne sont pas judicieusement choisis, le projet peut vite devenir un calvaire à maintenir ou à faire évoluer.

Gérer plusieurs types de base : Spring à la rescousse !

Pour cela, GoPivotal (anciennement SpringSource) a créé Spring Data : une librairie générique pour l’accès aux données. On peut ainsi accéder à des base orientées « document », « graphe » ou « clé-valeur » de manière unifiée. Cela permet d’avoir la même API que ce soit pour une base MongoDB ou une base Neo4j, par exemple.

Pourquoi avons-nous contribué ?

Dans le cadre d’un de nos projets, nous avons pu explorer différents aspects d’Elasticsearch (souvent considéré comme une base NoSQL). Nous utilisions déjà Spring Data pour les bases Redis (clé-valeur), Neo4j (graphe) et MongoDB (document) mais Elasticsearch ne faisait malheureusement pas encore partie de l’écosystème de Spring Data. Après quelques recherches rapides, un projet existait en open source. La partie géolocalisation était manquante et nous en avions besoin. Nous avons donc contribué à ce projet qui au fil du temps a été intégré à Spring Data Dijkstra.

Pour ceux qui codent : des exemples !

Voici comment faire des requêtes géolocalisées avec Spring Data Elasticsearch : Exemples de requête géolocalisée avec Spring Data Elasticsearch

Pour plus d’informations sur le projet : httpss://github.com/spring-projects/spring-data-elasticsearch

Monitoring des applications avec Kibana et Logstash

Dans les environnements avec de nombreuses applications ou dans les applications avec une architecture en micro service, il est important de mettre en place les bons outils pour surveiller les applications.

Surveiller les défaillances

Toutes les applications, sites web ou services peuvent défaillir. Il est important d’être capable de détecter rapidement la panne et si possible de restaurer le service, donc il faut disposer d’un outil de monitoring en temps réel.

Avoir les bonnes mesures

Pour faire les bons diagnostics, on doit disposer d’indicateurs qui sont à la fois informatique et business, par exemple :

  • Nombre d’appels à un service
  • Temps de réponse des services
  • Sollicitation des bases de données
  • Nombre de messages
  • Nombre de commandes par minutes
  • Actions des utilisateurs

La solution Kibana / Logstash

Nous avions déjà testé cette solution lors d’un POC, et depuis nous avons déployons cette solution pour nos clients.

Pourquoi utiliser les micro services pour une application ?

Une architecture en micro service (également appelé micro application ou encore small app) est une façon de concevoir les applications. Le principe est de créer un ensemble de petites applications (ou services) autonomes qui communiquent entre elles par un protocole simple (Ex : par API REST). Elles sont conçues pour répondre à une fonction business spécifique et doivent pouvoir être déployées facilement et indépendamment. Chaque micro service peut être écrit dans un langage de programmation différent ou utiliser des bases de données spécifiques.
Les retours d’expérience sur ce type d’architecture sont positifs et de plus en plus utilisés, au point où cela devient un standard pour les gros applicatifs.

Comparaison avec une architecture monolithique

Habituellement, les applications sont en 3 parties différentes: l’interface utilisateur (développée en HTML / JavaScript), une base de données (habituellement une base SQL) et une application côté serveur (développé en PHP, Java, Ruby, …). L’application côté serveur est responsable du stockage de la données et de la génération de l’HTML pour le front. Cela présente les inconvénients suivants :

  • Toute la logique de l’application se retrouve donc dans une seule application, écrite dans un seul langage de programmation. On n’exploite pas les capacités des différents (ex: R pour les statistiques)
  • Les modifications sur l’application peuvent impacter d’autres modules
  • Pour assurer la montée en charge, il faut une montée à l’échelle horizontale en déployant l’application au complet sur plusieurs serveurs
  • À chaque modification apportée à l’application, le cycle de développement est long (définition du fonctionnel, développement, tests, déploiement)
  • Au fil du temps, il est de plus en plus difficile de garder l’architecture modulaire prévue à l’origine
  • Chaque développeur doit avoir l’application au complet dans son environnement de développement et doit comprendre la majeure partie de l’application

Ces inconvénients ont conduit à penser les modules comme des services et l’application comme une suite de services. Chaque service est indépendant, avec une montée à l’échelle indépendamment, écrit dans différents langages et par des équipes différentes. La complexité de l’application est cassée en un ensemble de modules facile à maintenir. Certains architectes expliquent que le problème résolu par un service doit pouvoir être mentalement représenté.

Idéal pour les évolutions fréquentes

De plus en plus d’applicatifs et de sites web doivent évoluer constamment. L’architecture en micro service répond à l’enjeu qui repose sur l’équipe informatique qui doit pouvoir apporter des modifications sans ralentir les temps de développement. L’architecture se prête même très bien à la création des services « brouillons », idéal pour le lean startup.

Architecture idéale pour la tolérance aux pannes

Lorsqu’on développe une application en micro service, cela oblige à prévoir dans l’application qu’un service puisse être défaillant. D’abord, l’application peut continuer à fonctionner dans un mode dégradé. Ensuite, les services étant plus simples, il est plus facile de les restaurer. Une brique importante dans cette architecture est le monitoring en temps réel des services. Le monitoring doit fournir les bonnes mesures pour surveiller les échanges entre services.

L’avenir de l’architecture en micro services

Cette architecture est de plus en plus utilisée et a déjà mise en place avec succès pour de nombreuses applications et sites web. Cependant, ce design est encore récent et la durée de vie des applications n’ont pas encore atteint celle de certaines applications monolithiques.


Voir un exemple d’architecture en micro service pour un job board


Des questions, des remarques ou vous voulez tout simplement échanger ? Appelez-nous au 04 73 35 47 51

Spécialistes Data et Big Data à Clermont-Ferrand

Agaetis est une société spécialisée dans les solutions logicielles de stockage et d’analyse de données.

Notre service

Nous concevons, développons et maintenons des applications pour traiter la donnée. Notre expertise sur les technologies Big Data et les outils de fouille de données nous permet de répondre aux attentes suivantes :

Nos compétences

D’un point de vue technique, nous travaillons avec les technologies NoSQL les plus utilisées aujourd’hui : ElasticsearchMongoDB, Hadoop, Neo4jCephRedis, Cassandra. Pour le développement d’application, nous travaillons avec Python et Java.

Notre expérience

Notre équipe est composée d’ingénieurs ayant plus de 10 ans d’expérience. Les parcours sont hétérogènes, puisque certains ont évolué dans des startup, d’autres dans des SSII, à l’étranger ou en France. Agaetis existe depuis 2006 et nous avons pu intervenir sur de nombreux projets en région.

Implanté en Auvergne

Basée à Clermont-Ferrand, notre équipe intervient, pour les grands comptes régionaux, les SSII et les PME. Nous développons le plus de collaborations possible avec d’autres entreprises régionales dont les spécialités sont complémentaires aux nôtres: objets connectés, référencement, développement mobile, spécialistes Javascript, Ruby, infrastructure, graphisme, …
Cette approche collaborative nous permet de rester réactifs et de garantir un très bon niveau d’expertise.
Agaetis est également sponsor de Clermont’ech et membre du cluster Auvergne TIC.

Réalisation d’un prototype / preuve de concept sur le Big Data

 

La preuve de concept (POC)

Réaliser un POC permet de conforter les choix technologiques avant de consacrer des ressources à un projet (formation des équipes, recrutement, investissement matériel, …).
Cette étape est très utile dans les projets Big Data car elle permet de révéler rapidement les points sensibles (Ex : volumétrie, évolution de la structure de donnée, traitements à mettre en oeuvre, …) et de caractériser les contraintes et objectifs. Au terme de cette étape, les décideurs doivent disposer d’éléments factuels pour poursuivre les investissements.

Le prototype

Dans le cycle de développement d’un nouveau projet, il est nécessaire d’avoir des développeurs expérimentés lors du prototypage. Ils sont la garantie d’une bonne architecture logicielle et de la mise en place correcte des briques technologiques.
Pendant la réalisation du prototype, l’équipe Agaetis intègre et forme les développeurs qui assureront la maintenance et les évolutions de l’application développée. C’est une garantie pour le porteur de projet que la connaissance technique ne soit pas uniquement chez son prestataire.

Adopter les méthodes agiles et le « lean startup »

Dans les projets innovants, les besoins et contraintes s’affinent au fur et à mesure de l’avancement du projet. Il faut un pilotage permettant à la fois de faire des itérations courtes entre chaque livraison et maîtriser les coûts de développement.
L’équipe d’Agaetis travaille avec les méthodes agiles, comprend les enjeux business d’un projet. Cela lui permet de faire les bons arbitrages entre les développements et le coût, et surtout d’être réactive et efficace.

Prestations pour les projets innovants

Pour une entreprise, le caractère innovant d’un projet se définit souvent par la création d’un produit ou d’un service nouveau sur son marché. Lorsque ce projet nécessite la création d’un outil informatique (application, logiciel, service web, …), il faut investir sur un développement sur mesure. Si l’innovation se repose sur des concepts récents (Ex : Big data, objets connectés, …), le risque technique doit être maîtrisé pour éviter la dérive du projet.
L’équipe d’Agaetis a développé un savoir faire et une expérience sur les projets innovants et offre une prestation sur mesure:

  • Une intervention dès les premières étapes du projet jusqu’à la commercialisation
  • Un accompagnement tout au long du projet par des développeurs expérimentés
  • La réalisation de preuve de concept
  • Un développement avec les méthodes agiles et l’approche « lean startup »
  • L’intégration et la formation de développeurs embauchés par le porteur de projet qui assureront la maintenance et les évolutions après la commercialisation
  • L’aide pour recruter les meilleurs profils techniques pour la continuité du projet
  • Le lien avec les laboratoires de recherche

À lire également, notre décryptage du cycle de vie d’un projet informatique innovant, les risques techniques et les solutions.

Enjeux techniques d’un projet innovant

L’innovation dans les différents secteurs d’activité se repose très souvent sur le développement d’une technologie informatique. Voici quelques exemples de thèmes abordés dans les projets :

  • Traitement de données
  • Analyse d’information
  • Outils décisionnels
  • Objets communicants (objets connectés, capteurs, …)
  • Réseaux sociaux
  • Applications mobiles
  • Vente en ligne

Les entreprises ont une très bonne compréhension des enjeux techniques mais, au lancement du projet, ils n’ont pas les moyens humains pour y répondre. Ils doivent alors recruter, sous traiter ou encore s’associer avec des partenaires techniques.
Dans tous les cas, la solution est rarement idéale pour équilibrer les différentes variables: compétence technique, expérience, coût, délai de réalisation, confidentialité. De plus, lorsque l’entreprise fait appel à des fonds extérieurs, les investisseurs attendent également une garantie sur la réalisation de la partie technique.

Cycle de vie du projet d’un point de vue technique

Etude de faisabilité technique
La première étape du projet consiste à faire appel à un ou plusieurs experts pour évaluer la faisabilité du projet, d’estimer le développement nécessaire, d’identifier les verrous technologiques. Cela permet d’évaluer les délais de réalisation, le nombre de personnes et qualification, et les moyens techniques nécessaires
Choix technologiques
Avec l’aide des experts (base de données, algorithmes, …), et en fonction de la facilité à trouver des personnes qualifiées, l’architecte logiciel propose la solution technique pour réaliser le projet.
Développement du prototype
L’objectif de la première étape de développement est de lever les principaux verrous technologiques et de faire la preuve de concept. L’équipe technique qui travaille sur cette première version doit être compétente et expérimentée.
La compétence est nécessaire car l’architecture posée lors de cette étape devra servir le plus longtemps possible. Une mauvaise architecture conduit généralement à une explosion des coûts et une limitation dans l’ajout de fonctionnalités.
Idéalement, l’architecte logiciel et le chef de projet doivent être expérimentés. L’expérience garantit en général les bons choix et une bonne gestion du temps et des dépenses.
Développement de la première version commercialisable
A partir du prototype, on complète le développement avec tous les éléments qui permettent d’exploiter la technologie en opérationnel : interfaces utilisateurs, gestion des erreurs, traçabilité, optimisation, etc …
C’est une étape souvent chronophage mais nécessitant moins de compétences. Idéalement l’équipe est complétée avec des juniors.
Maintenance et évolutions
Une fois la technologie en exploitation, une équipe réduite s’occupe de la maintenance et des petites évolutions.

Profil d’une équipe de développement sur un projet innovant

Etude des différentes solutions pour réaliser techniquement un projet

Recrutement

Avantages

  • Une équipe travaillant en interne garantit la maîtrise et la connaissance du projet
  • Coût maîtrisé une fois que la technologie est en exploitation

Inconvénients

  • Difficulté à recruter des personnes compétentes et expérimentées, difficulté accrue dans certaines régions comme en Auvergne
  • Le recrutement de personnes techniques nécessite une bonne connaissance technique de la part du recruteur
  • Difficulté à donner la souplesse nécessaire à l’équipe (nombre de personnes, compétence, expérience) jusqu’à la mise en exploitation. Comme il est très difficile de recruter des personnes qualifiées en CDD, il faut donc faire appel à des indépendants, consultants ou des SSII pour avoir des personnes en régie.

Sous-traitance

Avantages

  • Prise en charge complète du projet par le prestataire
  • Obligation de moyen pour réaliser la prestation dans le délai imparti

Inconvénients

  • Tarif
  • Nécessite une personne dédiée au suivi de projet et une plus grande formalisation des échanges (contrat, cahier des charges, compte-rendus, comité de pilotage, …) entre les porteurs de projet et le prestataire
  • Le savoir faire technique et la connaissance de la technologie est chez le prestataire, même avec la rédaction de documents.

La solution Agaetis

Agaetis propose une offre dédiée à la réalisation de projets innovants :

  • Une intervention dès les premières étapes du projet jusqu’à la commercialisation
  • Un rôle de partenaire auprès des différents acteurs (banques, investisseurs, …)
  • Le recrutement et la formation des techniciens qui feront partis de l’équipe de développement et qui assureront la maintenance et les évolutions après la commercialisation

Une équipe compétente et expérimentée

  • Plus de 10 ans d’expérience
  • Les membres de l’équipe ont travaillé dans des startup et des grand-comptes

Une expérience dans les projets innovants

  • Depuis 2009, Agaetis gère régulièrement des projets innovants
  • Plusieurs projets étaient supérieurs à 6 mois

En lien avec les laboratoires de recherche

  • Relation privilégiée avec LIMOS et CEMAGREF/IRSTEA
  • Possibilité de créer des projets collaboratifs avec ces laboratoires

Recrutement et gestion des compétences

  • Grâce aux liens avec les universités et les écoles (plusieurs personnes d’Agaetis donnent des cours à l’Université, rencontrent avec les directeurs d’écoles par Auvergne TIC, …), Agaetis assure le recrutement de juniors
  • Les techniciens recrutés sont intégrés à l’équipe d’Agaetis où ils sont formés, ils contribuent au développement afin d’être autonome à la livraison finale
  • Les nouvelles embauches peuvent être subventionnées en région Auvergne

Crédibilité auprès des investisseurs
Agaetis travaille à créer un rapport de confiance avec les financeurs et se porte caution sur la technique

Référence : Plateforme opérationnelle de suivi de la pollution

Outil de prévision et de suivi des panaches de pollution.

Objectifs
Création d’une plateforme pour visualiser l’impact de l’activité d’une usine sur les concentrations des polluants autour du site.

  • Intégration des données d’émissions de l’usine et météo
  • Simulation en temps réel et prévisions jusqu’à 3 jours
  • Analyses de l’historique de l’activité (plusieurs mois à plusieurs années)

Réalisations

  • Intégration des données d’émission et météo
  • Exécution des modèles de dispersion et stockage des résultats
  • Visualisation et outils statistiques de la dispersion des polluants
  • Cartographies

Technologies utilisées

  • PostgreSQL / PostGIS
  • R
  • Java / Spring

Secteur : Environnement

Référence : Analyse et visualisation de données spatiales complexes – Bourse innovation

L’objectif du projet est de proposer de nouveaux composants informatiques pour permettre l’intégration, l’analyse et la visualisation des données spatiales complexes (grille).
L’intégration de ces données spatiales complexes se fait avec un système à base d’Entrepôt de Données GeoMondrian.


Technologies utilisées :

  • GeoMondrian

Secteur : Environnement
Durée du projet : Bourse innovation de 3 ans avec l’IRSTEA (anciennement CEMAGREF)

Référence : Système d’interprétation de données biologiques et génétiques

Cet outil d’aide à la décision pour la prescription à destination des médecins génère un rapport contenant tous les risques d’interaction médicament / gène.
C’est un moteur d’inférence dont les règles sont écrites par les scientifiques, par exemple « si le patient présente la mutation XX du gène YY et qu’il a tel antécédant, alors il faut éviter le médicament AAA ».
Le rapport final est un fichier PDF ou HTML.


Technologies utilisées :

  • Moteur d’inférence créé par Agaetis
  • Édition du rapport basé sur FOP
  • OWL / sémantique

Secteur : Santé
Durée du projet : 12 mois

Référence : POC GPS Outdoor

À partir de données collectées sur le terrain, ce GPS permet de créer des parcours outdoor en fonction de critères prédéfinis.

Les données collectées sont des portions de chemins (PR, GR, sentier) géoréférencés, annotés avec les conditions de praticabilités. L’utilisateur final peut demander un parcours, par exemple un parcours d’une heure avec des enfants en passant à côté de tel point de curiosité.


Technologies utilisées :

  • Neo4J
  • PostgreSQL

Secteur : Service
Durée du projet : 1 mois

Référence : POC Veille de prix et offres produits des sites e-commerce

Ce prototype permet d’analyser les offres produits des sites e-commerce.
À partir des informations récoltées sur les sites, la solution permet d’étudier les parts d’offres des fabricants par segment de produits.


Technologies utilisées :

  • MongoDB
  • Crawl-It : Système de crawling basé sur Selenium développé par Agaetis
  • JasperReports
  • Mondrian (cube OLAP)

Secteur : Service
Durée du projet : 6 mois

Référence : Job Board Social

Dans le cadre d’un prototype visant à créer un job board couplé aux réseaux sociaux, Agaetis a créé le prototype et a accompagné jusqu’à la mise en production.

Outre les fonctions classiques d’un job board (recherche d’annonces, candidathèque), la valeur ajoutée de ce nouveau service est de trouver des liens entre la société qui a une offre d’emploi et le chercheur d’emploi. Grâce à la connexion aux réseaux sociaux et aux informations renseignées sur le CV, le système est capable, pour chaque offre, de mettre en regard des personnes ayant des liens avec vous et l’entreprise (ex: parcours scolaire commun, ancien collègue, ami Facebook, …).


Technologies utilisées

  • Ceph : pour le stockage des CVs et photos
  • Elasticsearch : pour la recherche des annonces
  • Redis : pour le stockage des pré-calculs de parentés
  • Neo4j : pour le parcours du graph des parentés
  • MongoDB : pour le stockage des activités et profil des utilisateurs
  • PostgreSQL : pour la gestion des utilisateurs
  • Spring social
  • Spring data
  • Spring integration

Architecture en microservice

Schéma de l’architecture

Secteur : Emploi
Durée du projet : 6 mois

Référence : POC Elasticsearch / Kibana / Logstash pour gestion des logs applicatifs

Création d’une plateforme de stockage et d’agrégation des logs des applications d’un éditeur de logiciel.
Ce POC a permis de valider la pertinence de la solution pour avoir un outil de surveillance des serveurs et applications et pour diagnostiquer les problèmes en phase de production.


Technologies utilisées :

  • Elasticsearch
  • Kibana
  • Logstash

Secteur : Santé
Durée du projet : 2 mois

Référence : Analyse de données télématiques

Gestion de données massives issues de capteurs embarqués sur des véhicules et création d’outils à destination des analystes métiers.
Objectifs

  • Gérer un gros volume de données issues de capteurs embarqués sur les véhicules (CAN, EBS, TPMS, …)
  • Vérifier la qualité des données
  • Agréger les données pour les rendre facilement exploitable
  • Tester des nouveaux indicateurs pour les besoins business

Réalisations

  • Choix techniques
  • Architecture (base de données, outils d’analyses, …)
  • Développement des algorithmes d’analyses (data quality, agrégations, …)
  • Développement d’interfaces de visualisation des données

Secteur : Transport

Référence : POC Système de fichier distribué pour coffre fort numérique

Mise en place du Distributed File System (DFS) Ceph pour un coffre fort numérique.

Le projet consistait à tester l’utilisation de Ceph pour stocker les fichiers cryptés couplé à Elasticsearch pour gérer les métadonnées.


Technologies utilisées :

  • Ceph
  • Elasticsearch
  • Puppet
  • OpenStack Identity

Secteur : Santé
Durée du projet : 3 mois

Elasticsearch, un moteur de recherche et d’analyse de données

ElasticSearch est un moteur de recherche libre (open source) basé sur Apache Lucene. Il permet l’indexation de données sous forme de documents, leur recherche et une analyse de ces données en temps réel.
Lire sur notre article sur l’utilisation d’un moteur de recherche plein texte
Voir le site officiel de Elasticsearch

Etude de cas : stockage de données météorologiques

Le laboratoire de recherche LIMOS et les sociétés Agaetis et Numtech ont mené en partenariat une étude sur l’utilisation d’une base de données NoSQL orientée document pour stocker des données météorologiques. L’objectif de ce travail est de trouver une solution pour Numtech de gérer toutes les données utiles à son service météorologique. Les deux problématiques majeures sont l’hétérogénéité des données et le volume à traiter.
L’étude porte essentiellement sur les performances du système, autant au niveau de la vitesse d’insertion des données que sur l’évaluation de requêtes prédéfinies.

Gestion d’une grande masse de données hétérogènes (big data)

Le service de modélisation météorologique de Numtech a besoin des données d’observations et qui produit des données d’analyse et des données de prévision. Toutes ces données sont hétérogènes car les sources, les mesures, les schémas, les unités et la précision sont différents. Les grilles géographiques ont également des tailles, des pas et des projections différents ce qui implique des imprécisions géographiques.
Les volumes sont également importants car les données d’observation représentent environ 1 Go par jour et les données d’analyse et de prévision environ 100 Go par jour. Toutes ces données doivent être conservées sur une longue période car certaines requêtes peuvent être effectuées sur plusieurs années.

Requêtes attendues sur la masse de données

Pour cette étude, il est attendu que la solution puissent répondre à 3 types de requête:

  • (R1) une extraction de plusieurs paramètres (température, pression atmosphérique, …) en un point du globe, à une altitude et sur une période données
  • (R2) une extraction sur une zone de toutes les données stockées sur une période allant de quelques jours à plusieurs années
  • (R3) une requête d’agrégation sur des paramètres 2D ou 3D sur une zone précise, entre deux altitudes et sur une période de temps définie

Choix de MongoDB et comparaison avec MySQL

La taille des données et les contraintes de temps concernant notamment l’insertion amènent à considérer un système de gestion de données favorisant le passage à l’échelle. Deux types d’extensibilités sont à envisager :

  • l’extensibilité verticale, qui consiste à augmenter la capacité de la machine gérant les données
  • l’extensibilité horizontale qui privilégie l’ajout de nouvelles machines pour augmenter les ressources de stockage et de calcul, en facilitant le partitionnement des données entre elles. Cette dernière approche rend plus facile la gestion du coût matériel de tels systèmes.

En outre, de part le type d’accès requis (essentiellement en ajout de données pour ce qui concerne les contraintes d’efficacité), certaines propriétés des SGBD relationnels ne sont pas indispensables. Le théorème de CAP, excluant d’avoir à la fois la consistance des données, leur disponibilité, et leur partitionnement oriente l’approche vers les systèmes NoSQL. En effet, les SGDBR privilégient la consistance et la disponibilité au détriment du partitionnement, favorisant l’extensibilité verticale. Les systèmes NoSQL privilégient par contre l’extensibilité horizontale, dans la mesure où ils sont conçus pour faciliter le partitionnement des données. La capacité de stockage et son coût n’étant pas linéaire, ces bases de données distribuées sont plus avantageuses lors du passage à l’échelle de l’application. Les données manipulées étant hétérogènes, l’absence de schéma statique fortement structuré dans les bases NoSQL permet de palier aux difficultés habituellement rencontrées en terme d’évolution de la structure des données à stocker et de leur intégration dans un système permettant des requêtes homogènes.

Les tests

1er scénario : Insertion d’un jeu de données  correspondant à 7 jours d’observation en 3600 points, soit 825 000 relevés pour 6 millions de paramètres.
2 extractions (R2)  ont été exécutées, sur 2 zones géographiques différents et sur 2 périodes différentes (une période de 2 jours et une de 6 jours). Voici les temps de réponses:

 MySQLMongoDB
R2 (2 jours)10,3 s7,45 s
R2 (10 jours)160,61 s82,93 s

2ème scénario : Insertion de la température issue de la prévision météorologique avec des mesures sur 104 heures dans une grille de 335 x 327 points et sur 42 niveaux d’altitudes. L’opération d’insertion exploite les capacités multi-processeurs des machines modernes afin de traiter le plus rapidement possible cette grille. Les données sont post-traitées puis distribuées sur 3 noeuds selon un clé représentant un « geohash » du point traité. Chaque noeud peut être répliqué afin d’assurer tolérance aux pannes et haute disponibilité. Le volume total de données en base est ici de l’ordre de 40 Go. Chaque heure de prévisions est représentée par un fichier distinct qu’il convient d’insérer en un maximum de 2 minutes compte-tenu des contraintes induites par une chaine opérationnelle déjà en place.
Les requêtes d’interrogation sont les suivantes:

  • R1 : 1 point, 1 paramètre, toutes altitudes, sur 6h. Cette requête retourne les 8 points les plus proches.
  • R2 : 1/10 de la grille, 1 paramètre, toutes altitudes (42), sur 6h
  • R3 : agrégation d’un paramètre sur une zone, sur 42 altitudes, pendant 3h.
 MySQL
R19,16 s
R267,98 s
R313,12 s

Les requêtes R2 et R3 traitent les m^emes données, mais R3 exploite pleinement les capacités de calcul de la machine par le biais de l’utilisation du Map Reduce.

Conclusion

Le prototype a permis de répondre aux contraintes (volumes, temps de réponses, …) et une première version a été déployée en production.
Une deuxième étape du projet est consacrée à étudier l’apport de la technologie Hadoop pour l’analyse de données distribuées. En effet, Hadoop est plus optimisé pour le Map Reduce ce qui peut améliorer les performances des requêtes d’interrogations, notamment en cas d’agrégation.

Partenaires

LIMOS , Numtech

Solution de cache HTTP, Varnish Cache

Le cache HTTP Varnish Cache est un outils qui permet de réduire le temps de réponse d’un site web et de réduire la sollicitation des serveurs web.

Principe du cache HTTP

  1. Le cache HTTP intercepte les requêtes utilisateurs (ex: https://www.agaetis.fr)
  2. Le cache demande au serveur de générer la page
  3. Le cache va garder en mémoire le rendu de la page
  4. Lorsqu’on un autre utilisateur va demander la même page, le cache va lui envoyer directement le résultat, sans demander au serveur de générer à nouveau la page

Avantages du cache

  • Réduction du temps de chargement d’une page. La plupart des pages web nécessitent l’exécution de code et de nombreuses requêtes à la base de données pour être créées.
  • L’utilisation du cache évite de solliciter le serveur web à chaque demande d’un utilisateur

Voir aussi une présentation technique de Varnish Cache.
Voir le site de Varnish Cache.

Moteur de recherche Full Text (Recherche Plein Texte)

Nous fournissons, sous forme de service ou d’accompagnement, une solution de moteur de recherche Full Text avec Elastic Search.
Un moteur de recherche Full Text, ou Plein Texte, est un outil conçu pour indexer les contenus textuels, tel que des articles de blog, des descriptions de produits ou encore des annonces.

Auto-complétion, suggestions et corrections

Pour améliorer l’ergonomie du site ou pour guider simplement l’utilisateur dans sa recherche, les outils suivants peuvent être mis en place:

  • auto-complétion : le moteur suggère des mots clés au fur et à mesure que l’utilisateur tape dans la boite de dialogue
  • suggestion: au résultat d’une recherche, le moteur propose des mots clés alternatifs, complémentaires ou plus restrictifs
  • correction: le moteur suggère des mots avec la correction des erreurs de frappe

Des résultats plus pertinents

Le moteur permet de répondre rapidement à différents type de requêtes telles que :

  • la recherche d’expression (ex: « améliorer son site web »). Elle diffère de la recherche exacte car le moteur prendra en compte des textes qui contiennent des espaces en trop.
  • la recherche de proximité (ex : améliorer site). Le moteur affichera en premier lieu les textes dont les mots sont les plus proches.
  • la recherche floue (ex: améliore site). Le moteur peut rendre des résultats dont la syntaxe est proche.

Des critères plus variés

Le moteur permet de restreindre ou filter les résultats grâce à des critères complémentaires, comme par exemple:

  • une période temporelle 
  • une localisation ou un périmètre géographique
  • des catégories

Catégorisation des résultats

Afin d’aider l’utilisateur à affiner sa recherche, le moteur liste les catégories auxquelles les résultats appartiennent.

Des temps de réponses plus rapides

Que ce soit le volume de données à traiter ou le nombre de requêtes qui augmentent, la solution Elastic Search a été conçue pour être facilement dimensionnée.

Intégration technique facile

Grâce à une API REST, l’intégration technique de ce moteur de recherche se fait facilement grâce au javascript.

Préservation des performances du site web

Les serveurs Elastic Search sont complètement autonomes, ce qui permet de préserver les ressources des serveurs du site web. Peu importe le nombre de recherches effectuées, le reste du site n’est pas impacté en terme de performances.