Keynote d’ouverture : la tech dans l’agri
Alexandre SIGUIER David DALLAGO
Pour la keynote, les organisateurs nous ont proposé une immersion chez un agriculteur pratiquant l’agriculture de précision. Effectivement, la haute technologie et l’agriculture mobilisent des imaginaires qui semblent incompatibles. L’objectif de la keynote est de montrer tout ce qui se fait déjà dans le monde de l’agriculture, de la culture céréalière notamment :
- Cartographie des parcelles
- Analyse des sols, notamment la profondeur du sol vs. roche
- Adaptation des semences et intrants aux spécificités des sols
- Utilisation du GPS pour le tracé des sillons et des passages du tracteur
- Utilisation du GPS pour programmer le semoir
- et bien d’autres fonctionnalités
Dans la dynamique actuelle de l’agriculture, la haute technologie permet à un agriculteur d’augmenter considérablement la taille des parcelles exploitées, et d’optimiser les intrants (les apports à une parcelle agricole destinés à augmenter ses rendements), à la fois pour des raisons écologiques et économiques (prix des intrants).
A l’aube des enjeux environnementaux et climatiques, les solutions technologiques présentées ici promettent d’optimiser le rendement des parcelles afin de :
- Demeurer compétitif sur un marché de l’agriculture complètement mondialisé
- Optimiser l’utilisation des produits phytosanitaires
Bonus, un des tracteurs de l’agriculteur était disponible sur le parking et disponible à la visite.
Le cloud des restos du cœur
Alexandre SIGUIER Guillaume GURFINKIEL Swanny LORENZI Tanoh N'GOYET David DALLAGO
La conférence est présentée par Julien Briault, aujourd’hui Network Engineer chez Deezer, et bénévole aux restos du cœur depuis plusieurs années.
Lors de cette conférence, il présente comment il a mis en place une infrastructure physique pour héberger des services Cloud, basés sur OpenStack, en s’appuyant sur des machines récupérées auprès d’entreprises (Michelin, Deezer). Cette réutilisation de machines illustre bien qu’on peut rendre bien des services avec du matériel “à décommissionner” (et d’un point de vue écologique, ça interroge)
Il justifie ses choix, en racontant l’histoire : il a démarré dans une antenne départementale, et a monté petit à petit des services pour toute la France, en partant d’un serveur simple hébergé dans des WC désaffectés jusqu’à la mise en place d’un data center dans des locaux nationaux. Il explique notamment que le choix d’un cloud public (AWS, OVH ou autre) n’est pas pertinent pour le contexte des restos, chez qui “un euro dépensé, c’est un repas non distribué”. Retenez cette valeur, elle guide énormément tous les choix.
Son objectif est de dépenser le moins possible tout en fabriquant une infrastructure gérable par deux salariés et 6-8 bénévoles. Il a notamment l’ambition d’éviter les astreintes, ce qui l’amène à utiliser des technologies résilientes comme Ceph pour le stockage distribué.
Il explique aussi rapidement la mise en place d’un service de supervision des salles réfrigérées (IOT).
Le travail fourni est impressionnant en assez peu de temps (4 ans) et donne le sentiment que les restos du cœur sont aujourd’hui très bien outillés par rapport à leurs enjeux.
Nous pouvons tirer d’importants apprentissages de ce retour d’expérience :
- Avec peu de personnes, motivées et compétentes, il est possible de faire beaucoup
- Une direction claire entraînant des décisions naturelles (1€ dépensé = 1 repas non distribué, pas d’astreintes, il faut viser la frugalité)
- Une construction incrémentale dirigée par les besoins et partant de la base (le département, la région, le national) aboutit à un service pertinent et adapté aux enjeux de l’organisation. Ici, le cloud privé répond parfaitement au besoin des restos du coeur
- Dans certains cas, avoir son datacenter on-premise est plus pertinent que le Cloud Public, pour des questions de coûts
Open-source sans burn-out ? Le modèle CNCF
Conférence présentée par Damien MATHIEU ingénieur logiciel chez Elastic et contributeur sur le projet OpenTelemetry.
De manière générale, maintenir un projet open source constitue une activité intéressante qui permet d’apprendre de nouvelles choses, partager le résultat de son travail avec d’autres, mettre en avant ses compétences techniques, etc.
Pourtant à première vue, il semblerait que de nombreux mainteneurs de projets open source rencontrent de grandes difficultés à maintenir leurs projets car ils effectuent cette activité seuls (ils sont les seuls contributeurs de leurs projets) de manière bénévole sur leur temps libre. Si pour une raison ou une autre le mainteneur d’un projet de ce type décide à un moment donné que ce projet ne fait plus partie de ses priorités, il peut arrêter de maintenir le projet ou continuer à le faire mais sans grand intérêt. Il en résulte que le projet peut être abandonné faute de mainteneur pour le prendre en charge et le faire évoluer.
Or, de nombreux petits projets open source sont utilisés comme dépendances par des projets plus volumineux. Par conséquent, un problème de sécurité affectant un petit projet non maintenu peut impacter le projet qui s’en sert comme dépendance. Cette situation a été représentée dans l’image ci-dessous par le site de bande dessinée en ligne xkcd.
L’image permet d’illustrer le cas typique d’une infrastructure logicielle moderne faite de modules dépendants les uns des autres et dans laquelle un module stratégique peut en réalité avoir été développé par un mainteneur qui maintient tout seul son projet de manière bénévole sur son temps libre. Une telle infrastructure est fragile car quelques-uns des petits projets sur lesquels elle repose sont susceptibles d’être abandonnés à tout moment par leur unique mainteneur. L’on peut aisément deviner en observant l’image que si le petit projet sur lequel repose en partie l’infrastructure est supprimé par son unique mainteneur, l’infrastructure toute entière risque de s’effondrer, telle un Jenga. Des incidents tels que celui de la compromission de XZ Utils et celui du paquet npm left-pad rappellent la vulnérabilité de certaines infrastructures logicielles modernes aux attaques ciblant les chaînes d’approvisionnement logicielles.
Cela dit, peut-on pour autant en déduire que l’open source ne fonctionne pas et est un échec ? Non, car alors que certains projets open source ne disposent que d’un seul mainteneur, d’autres projets open source tels que Kubernetes, Firefox ou Wordpress rencontrent un assez franc succès et de nombreuses personnes contribuent à maintenir ces projets. Quel est donc le secret des projets open source qui parviennent à un tel niveau de viabilité ? Et comment l’appliquer à votre propre projet open source ?
Il n’y a pas de recette miracle, tout dépend de la manière dont fonctionne votre projet et de l’orientation que vous comptez donner à votre projet. Prenons par exemple le cas du projet OpenTelemetry. OpenTelemetry est un projet géré par la CNCF (Cloud Native Computing Foundation). La CNCF gère de multiples projets dont certains sont de gros projets tels que Kubernetes et OpenTelemetry. L’objectif de la CNCF n’est pas d’écrire les lignes de code des projets qu’elle prend en charge ou de les maintenir de manière explicite, mais plutôt de favoriser une bonne gouvernance et une bonne viabilité des projets dont elle a la charge. Cela passe par la mise en place de bonnes pratiques et la mise à disposition de moyens tels que des moyens de sécurité (analyses de sécurité), financiers, de conférences, etc.
OpenTelemetry est un métaprojet, c’est-à-dire qu’il est constitué de dizaines d’autres projets appelés SIGs (Special Interest Groups) parmi lesquels l’on peut citer OLTP, Collector, Semantic conventions, etc. OpenTelemetry décrit plusieurs niveaux de contribution tels que “member”, “triager”, “approver”, “maintainer”. Cela permet une meilleure répartition des rôles et des responsabilités entre les différents contributeurs.
Pour favoriser la communication au sein des SIGs, chaque SIG se retrouve régulièrement de manière synchrone, par exemple en visioconférence toutes les semaines ou tous les 15 jours. Cela permet de discuter plus efficacement des problèmes potentiellement bloquants ou d'obtenir un consensus difficile à trouver, contrairement à un cas où les échanges se feraient uniquement par écrit.
Afin de favoriser une bonne coordination du projet OpenTelemetry dans son ensemble, le projet dispose de deux comités :
- un comité technique qui est responsable du processus de développement et des standards. Son rôle est d’assurer la médiation de consensus technique entre les SIGs. Ce comité est constitué d’experts du projet et apporte une vision technique globale au projet. Les membres du comité sont élus par leurs pairs c’est-à-dire par des experts du projet.
- un comité de gouvernance qui est chargé de définir et de maintenir la vision, les valeurs et les objectifs du projet. Ses membres sont élus par la communauté.
Le rôle des deux comités est d'assurer la médiation entre les SIGs. Chaque SIG dispose de deux sponsors qui sont membres de l’un ou de l’autre des comités et dont le rôle est de s’assurer que la SIG fonctionne comme prévu.
Revenons maintenant à la question de savoir comment rendre votre projet open source viable et vous assurer que les projets que vous utilisez sont également viables. En prêtant attention au cas d’OpenTelemetry qui est un projet open source disposant d’un grand nombre de contributeurs, son modèle de gouvernance peut être une source d’inspiration pour obtenir des idées sur une manière efficace (parmi d’autres) de gérer la maintenabilité d’un grand projet open source. Toutefois, vous ne devez pas chercher à appliquer exactement le même modèle de gouvernance qu’Open Telemetry à votre projet open source surtout s’il s’agit d’un petit projet car un petit projet n’est pas confronté aux mêmes problématiques d’échelle qu’un grand projet.
Il n’y a donc pas de recette miracle à mettre en place, tout dépend de ce que fait votre projet, de sa taille, son contexte, son historique, etc. Une chose qu’il serait tout de même bien de faire avant de démarrer votre projet, c’est de déterminer l’objectif de ce projet : s’agit-il d’un projet de découverte, d’apprentissage d’une technologie ou d’un projet destiné à aller en production ? L’objectif de votre projet peut bien évidemment changer avec le temps mais vous devriez le définir avant de lancer le projet.
S’il s’agit d’un projet de découverte alors la question de la viabilité de votre projet ne se pose pas car le projet n’est pas destiné à aller en production ; vous pouvez le supprimer à tout moment sans grande conséquence. Cependant, pensez à bien documenter le fait que votre projet ne devrait pas être utilisé en production (afin que les personnes qui aimeraient s’en servir en production évitent de le faire) et qu’il peut disparaître du jour au lendemain.
A l’opposé, s’il s’agit d’un projet destiné à aller en production, alors vous ne savez pas dès le début du projet si ce projet servira uniquement pour votre propre usage ou s’il sera en fin de compte utilisé à large échelle, par de nombreuses autres personnes et entreprises. Dans ce cas vous devriez :
- trouver un sponsor pour financer votre projet, par exemple votre employeur. Si la problématique qui vous amène à créer le projet est une problématique que vous rencontrez dans votre travail, il n’y a pas de raison que vous travailliez sur le projet le soir et le weekend car le premier bénéficiaire du projet sera votre employeur. Obtenez donc l’assentiment de votre employeur pour travailler sur le projet pendant vos heures de travail et évitez d'y travailler le soir et le weekend, sinon vous risquez de vous épuiser. Une chose que vous devez absolument retenir est que les projets open source viables ne sont jamais (ou sont très rarement) des projets effectués uniquement les soirs ou les week-end. La grande majorité des projets open source viables disposent d’un sponsor financier.
- commencer dès le début du projet à construire une communauté autour de votre projet au lieu de vous empresser d’y contribuer tout seul. Essayez dès le départ de trouver des personnes qui rencontrent les mêmes problématiques que vous et qui désirent travailler avec vous sur le projet. Cela vous permettra de ne pas être le seul contributeur du projet. Une des manières de le faire est de ne pas vous empresser de résoudre vous-même les “quick fixes”, c’est-à-dire les bugs rapides à corriger. En effet, en tant que mainteneur du projet, vous avez une bonne connaissance de la base de code, des zones de difficultés dans le code et de la direction que doit prendre le projet. Évitez donc le plus possible de corriger vous-même les quick fixes mais laissez le soin à d’autres personnes qui désirent commencer à contribuer au projet de le faire car ce sera d’excellentes occasions pour ces personnes de se familiariser avec votre base de code et de la faire évoluer par la suite.
- Apprenez à dire non plus souvent que vous ne dites oui. Par exemple, si un utilisateur vous demande une nouvelle fonctionnalité, la première bonne réponse que vous devriez donner est probablement non. Si en fin de compte l'utilisateur réussit à vous faire changer d’avis ou que vous avez un grand nombre d’utilisateurs qui demandent cette fonctionnalité, vous pourrez alors si vous le souhaitez accepter cette fonctionnalité. L’idée derrière ce principe est que vous pouvez toujours revenir sur un non en changeant d’avis plus tard. Or, si vous dites oui d’entrée de jeu, cela vous engage en quelque sorte devant vos utilisateurs et vous aurez du mal à retirer la fonctionnalité par la suite. En effet, si un jour pour une raison ou une autre vous décidez de retirer une fonctionnalité, un certain nombre de vos utilisateurs vont probablement s’en plaindre en vous faisant comprendre que cette fonctionnalité leur est utile et que si vous retirez la fonctionnalité, ils cesseront d’utiliser votre projet. Si cela arrive, vous risquez de perdre une bonne partie des utilisateurs de votre projet, ce qui serait dommage
Quoi qu’il en soit, peu importe l’objectif de votre projet open source, pour vous assurer que les autres projets open source que vous utilisez sont également viables, cela va probablement nécessiter quelques ajustements de votre part. Si vous utilisez des projets open source sans y contribuer à minima en signalant des bugs ou financièrement, cela ne favorise pas la bonne viabilité du projet. Vous pouvez par exemple contribuer à la viabilité des projets open source que vous utilisez en les sponsorisant. Cela pourrait donner plus de motivation au(x) mainteneur(s) du projet pour continuer à s’investir dans le projet. Pour favoriser le financement durable des projets open source, le consortium Open Source Pledge encourage les entreprises à payer 2 000 $ par développeur et par an.Si vous ne désirez pas ou ne pouvez pas contribuer financièrement à un projet open source que vous utilisez et dont vous aimeriez augmenter la viabilité, la solution pour rendre à ce projet les avantages qu’il vous procure est d’y contribuer :
- soit de manière occasionnelle en corrigeant les bugs lorsque vous les découvrez
- soit de façon régulière et sur le long terme en devenant un mainteneur du projet
Plongez dans l’Univers XR : Du Réel à la Réalité mixte, l’Expérience Immersive de Demain !
Conférence présentée par Axel SIMON et Jérôme JAMES
J’ai choisi cette conférence par curiosité, mes contacts avec les univers de réalité augmentée ou virtuelle se faisant surtout à travers des jeux vidéo. Mais qu’en est-il dans un cadre plus professionnel, grand public ? Et que signifie “XR” d’ailleurs ?
Pour y répondre, commençons par quelques définitions.
XR signifie eXtended Reality, ou réalité étendue
Il s’agit ni plus ni moins du domaine regroupant les différentes réalités : l’AR, la VR, la MR.
Voyons-les plus en détail sans plus attendre.
AR signifie Augmented Reality, ou réalité augmentée
Elle consiste en la superposition d’images virtuelles sur une prise de vue réelle, essentiellement sur l’écran d’un smartphone filmant les alentours.
Son principal atout est sa facilité de mise en place : tout le monde ou presque a un smartphone avec une caméra. Une application téléchargée plus tard, et l’AR est disponible.
Cet atout est aussi sa principale limite : les capacités d’immersion visuelles et auditives offertes par un smartphone sont très limitées.
Comme exemple d’usage professionnel, on peut citer l’application mobile Ikea.
Elle permet de prévisualiser des meubles en environnement réel, pour voir s’ils sont à la bonne taille, si la couleur convient, etc.
Son développement a été motivé par un grand nombre de retours, des clients achetant un meuble pour se rendre compte après coup qu’il ne rentre pas dans leur pièce à quelques centimètres près, et ensuite le ramener en magasin pour échange.
L’application a permis de réduire de façon importante ces retours de meubles tout en augmentant le taux de conversion, les clients prévisualisant leurs meubles dans l'appli ayant beaucoup plus tendance à acheter.
VR signifie Virtual Reality, ou réalité virtuelle
En réalité virtuelle, le spectateur est plongé dans un environnement totalement virtuel, isolé, au moyen d’un casque couvrant tout son champ de vision et son espace auditif.
Le principal avantage de la VR est de fournir un espace entièrement dédié à l’expérience, et de permettre une concentration maximale du sujet.
Là aussi cet avantage est aussi son défaut : le spectateur ne percevant plus le monde réel risque de heurter des obstacles, de se blesser, de blesser d’autres personnes.
Il encourt aussi le risque de subir le mal des transports (motion sickness), quand l’expérience virtuelle - et les éventuels déplacements - entrent en conflit avec ses autres sens (équilibre, etc).
Comme exemple d’usage professionnel, on peut citer les programmes de formation à la sécurité en usine.
L’utilisateur est plongé dans des scénarios présentant des situations à risque et doit apprendre à réagir avec les bons gestes, les bons réflexes.
Par exemple, il se situe dans un grand hall d’usine et veut traverser un couloir marqué au sol, mais il oublie de regarder à droite au moment où un chariot arrive => accident, game over (l’écran présenté en démonstration lors de la conférence affichait même une tête de mort en guise de game over, on n’est vraiment pas loin d’une expérience de jeu vidéo).
Ce genre d’expérience permet d’obtenir de meilleurs résultats par rapport à de simples documents à lire ou de vidéos à regarder.
MR signifie Mixed Reality, ou réalité mixte
C’est en fait un mélange de VR et AR, où le casque utilisé ne masque plus l’environnement réel, mais au contraire superpose les éléments de VR par-dessus la prise de vue réelle.
Contrairement à un smartphone (AR), l’immersion est beaucoup plus forte. Par contre, ça demande un matériel adapté.
Comme exemple d'usage, les présentateurs ont montré une situation où le spectateur intervient sur une machine dans une usine, tout en étant en réunion visio avec un collègue.
La visio se superpose à la scène dans un cadre affiché à côté de la machine, et des éléments de la machine avec lesquels il doit interagir sont mis en surbrillance.
Et du coup, comment peut-on mettre une “XR” en place ?
Là ça devient intéressant car on rejoint un peu le domaine des jeux vidéos.
La réalisation d’applications d’AR, VR ou MR passe par du développement sur des moteurs 3D comme Unity ou Unreal Engine, comme pour la plupart des jeux vidéos, et avec les mêmes défis et contraintes.
Ces moteurs s’accompagnent aussi de “magasins d’assets” plus ou moins fournis pour construire rapidement un environnement virtuel sans tout devoir créer de zéro (ce qui demanderait des compétences en design 3D)
Face à la diversité des matériels sortis sur le marché (casques virtuels, lunettes), une norme appelée OpenXR a été définie, et permet de rendre les applications compatibles avec les différents matériels disponibles.
Au final, quel avenir pour tout cet univers ?
Les technologies XR se basent déjà sur des solutions pérennes (moteurs 3D déjà bien installés sur le marché, norme OpenXR) et permettent de mettre en place des applications viables sur du long terme.
A part pour l’AR, le matériel nécessaire est pour le moment assez lourd, la génération d’images virtuelles nécessitant pas mal de puissance. Cependant comme partout ailleurs, le matériel s’améliore, devient plus léger, plus efficace.
L’avenir pourrait même s’alléger encore plus : en combinant la 5G et le cloud computing pour déporter le calcul hors du matériel, il sera possible de ne porter que des lunettes légères à la place des masques imposants actuels.
Du CSS aux shaders WebGL : panorama des techniques d’animation
Lors de cette conférence, Julien nous a parlé des enjeux liés à la création d’animations pour le web, tout en mettant l’accent sur l’importance d'écrire une expérience fluide et immersive aux utilisateurs.
Les animations web, notamment avec des technologies comme WebGl, permettent de repousser les limites graphiques. Elles ouvrent la porte à des rendus impressionnants (quand elles sont maîtrisées) mais leur utilisation nécessite de garder en tête un enjeu majeur : ne pas gêner l’utilisateur, de par la lenteur d’animation mais aussi préserver la performance pour garantir une navigation agréable. Des animations trop lourdes / longues peuvent ralentir et frustrer les utilisateurs, nuire à son expérience malgré un visuel attrayant.
Julien nous fait part de plusieurs outils et techniques, permettant de produire des animations toutes aussi percutantes sans alourdir le processus :
Transformation CSS : Souvent sous-estimées, elles permettent d’obtenir des résultats efficaces tout en allégeant les calculs nécessaires, utilisant le thread GPU.
Web animation API : Idéal pour un contrôle précis des animations, notamment celles qui interagissent avec le défilement de la page, ou d'autres comportements dynamiques plus complexes à gérer avec du CSS pur.
Pour répondre au besoins variés, voici quelques bibliothèques à garder à l’oeil :
- Framer Motion / Motion one, idéales comme web animations API
- LottieFiles, qui facilite l’intégration d'animation complexes, comme des illustrations animées
- Three.js, pour une intégration 3D
Un des grands messages de la conférence est que l’efficacité ne repose pas uniquement sur la maîtrise technique. Il s’agit aussi de savoir choisir les outils adaptés au projet.
