SnowCamp 2023

Pulumi et l'AWS Cloud Developement Kit (AWS CDK) ont ouvert une nouvelle ère pour l'infrastructure-as-code. Jusqu’à maintenant, nous utilisions principalement des langages déclaratifs pour décrire les ressources d'infrastructure dont nous avions besoin. Cela permet d'automatiser complètement le déploiement de l'infrastructure et de rendre celui-ci répétable de manière consistante à l'envie. Cependant, tester ces modèles d’infrastructure sans déployer s’avère complexe, les décomposer en module réutilisable est fastidieux et l’auto-complétion dans les IDE est pauvre.

Pulumi et AWS CDK amène à l’infrastructure-as-code à un nouveau niveau en permettant aux développeurs d’utiliser leur langage de programmation favori pour développer, tester et déployer leur infrastructure. Ils peuvent exploiter toute la puissance d’abstraction de leur langage, créer facilement des packages réutilisables et bénéficier d’une auto-complétion performante.

Dans ce workshop, vous allez coder votre première infrastructure-as-code avec un des 4 langages proposés : TypeScript, Java, Python ou C#.

Dans cette université nous partirons d'une application (java) sobre en terme d'observabilité. Nous rajouterons progressivement les logs, les traces, les m"triques pour finalement avoir un système observable et observé.
Pour ce faire, nous utiliserons prometheus, grafana, tempo, loki et promtail et nous configurerons petit a petit les différents pipelines dont nous aurons besoin pour voir les pièges a éviter et re-parcourir les bonnes pratiques.
Matériel nécessaire : un laptop par binôme, docker installé et le plugin docker compose, nous fournirons les images de départ
Ce que les participants apprendrons /retiendront :

* avoir un système observable c'est possible et simple aujourd'hui
* manipuler les différents librairies de log/trace/metric
* manipuler les outils permettant de collecter / partager / agréger / visualiser les informations utiles
* avoir un vision du système au métier en passant par l'application

Technologies: springboot, sleuth, opentelemetry, grafana, prometheus, loki, tempo, promtail

This workshop is designed to be a hands-on experience on how developers can get started with scaffolding serverless functions projects using Quarkus, a new Kubernetes native Java framework with familiar tools (e.g. CLI, Maven, Gradel). The workshop covers deploying service functions to AWS Lambda, optimizing the functions, making them portable across multiple serverless platforms ( e.g., AWS Lambda, Azure Function, Google Cloud Platform, Kubernetes Knative), and using the latest handy command-line tool (e.g. Kn func) to enable a Buildpack for function development & deployment in minutes. Lab participants will be provided a free sandbox for serverless deployments.

This hands-on lab showcases how quickly developers can create cloud-native microservice projects using Quarkus. Then, the application can be deployed to a function to AWS Lambda and Knative Event with JVM and Native mode.

Gitlab, dans toutes ses versions, propose de nombreuses fonctionnalités pour mener à bien un projet de bout en bout et pas uniquement de l'hébergement de code source et de la CI.

Dans ce workshop, nous proposons aux participants de découvrir l'ensemble des fonctionnalités *gratuites* via un projet de démo :

- **Gestion du projet**
- Issues
- Sécurité
- Configuration (branches, ...)
- **Développement**
- Source
- CI (Code quality / Test / SAST analyzer)
- Artefact / Registry
- Merge request / Processus de review
- **Release**
- **Déploiement**
- Environnements
- Déploiement sur une plateforme cible
- **Pages**

En sortant de ce workshop, les participants auront une vision globale des possibilités proposées par l'outil dans sa version gratuite.

L'heure est grave, en tant qu'agent du CYPRESS, qui s'est imposé ces dernières années en tant que leader incontournable des tests E2E, vous êtes maintenant challengés par Microsoft lui-même avec Playwright!

Proposant les mêmes services, il résoud également tous les problèmes rencontrés par Cypress, comme:
- le test multi pages ou multi onglets
- la restriction d'iframe ou de third-parties, vous pouvez utilisez votre application tel quelle
- support des 3 navigateurs majeurs (chromium, firefox et webkità
- support de l'API d'assertion de jest et plus recemment l'API de sélection de testing-library
- native typescript et async/await support

Votre mission est donc simple: Espionnez ce nouvel outil pour vous faire une idée de la dangerosité qu'il apporte à Cyrpress et trouver les codes d'accès des secrets de Microsoft...

Quand on souhaite publier des APIs avec par exemple, une solution d' API Management, on évoque régulièrement le versionning. Cette pratique répond à des contraintes projet mais apporte malheureusement son lot de complexité.

Imaginez, vous travaillez sur un produit qui expose des APIs à plusieurs clients. Vous devez leur proposer des évolutions et nouvelles fonctionnalités tout en maîtrisant l'existant.
Comment faire évoluer et proposer vos APIs à certains clients sans pénaliser les autres? Quelle stratégie adopter? Quelles solutions techniques peut-on mettre en place simplement?

Lors de cet atelier, vous (re)découvrirez et mettrez en pratique des conseils que j'ai pu mettre en oeuvre et qui m'ont aidé lors de mes derniers projets.

Au travers d'un cas concret basé sur une architecture microservices, nous allons définir la stratégie à mettre en oeuvre, les différentes possibilités d'implémentation ainsi que leurs contraintes.
Nous les challengerons ensuite en apportant différentes évolutions (ajout d'un nouveau client ou de nouvelles fonctionnalités).

A l’issue de cet atelier, nous aurons une vue complète et mis en pratique différentes manières d'appréhender le versionning d'APIs.

Les pré-requis pour cet atelier sont disponibles ici

Comment démarrer une chaîne de confiance ? Comment gérer automatiquement la rotation de vos secrets et clés de sécurité (révocation et renouvellement) ? Comment en finir avec les Post-It de mot de passe collés sous le clavier de vos collègues ?

Si ces sujets vous hantent toutes les nuits, la cybersécurité est un sujet qui vous tient à cœur !

Rejoignez-nous dans ce workshop autour de **Hashicorp Vault** et des bonnes pratiques de sécurité dans le cloud. Venez découvrir comment opérer un cluster Vault, comment intégrer une nouvelle application dans votre chaîne de confiance, comment établir une stratégie de policies et encore beaucoup de choses indispensables à la sécurité.

Une stack de test sera mise à disposition pour tous les participants (Docker dans un premier temps et si vous êtes sages, on pourrait tester la plateforme managée Squarescale).

Découvrons les fondamentaux des architectures microservices et comment les implémenter, du code au monitoring en production, en utilisant Node.js, Docker et Azure.

On va construire une application complète, incluant un site web avec authentification et 3 microservices, déployer le tout sur Azure avec un pipeline CI/CD et effectuer des tests de charge pour ajuster le scaling de nos services, voir comment utiliser le log tracing et le monitoring. Et on n'aura même pas besoin de Kubernetes!

**Au programme**:
- Rappel des principes de base des microservices et ses avantages
- Création de services Node.js avec 3 frameworks différents
* NestJS
* Fastify
* Express
- Containerisation des services avec Docker
- Utilisation des Docker multi-stage builds
- Connexion des services à leur base de données
- Mise en place d'un pipeline CI/CD avec GitHub Actions
- Déploiement des services sur Azure Container Apps
- Tests de charge et scaling
- Log tracing et monitoring

Les opérateurs Kubernetes prennent de plus en plus de place de place dans l'éco-système Kubernetes.
Un Opérateur simplifie le packaging et le déploiement des applications au sein de Kubernetes mais il permet aussi d'automatiser la partie opérationnelle telle que les mises à jour, les migrations etc ...

Après une rapide présentation sur les concepts clefs des opérateur ce workshop sera l'occasion de plonger concrètement dans les profondeurs du développement d'un opérateur.

Développer d'accord, mais avec quel langage ?

Pour nous, vieux développeurs, le choix était évident : Java ! Et comme on adore Quarkus, autant méler l'util à l'agréable, c'est avec Quarkus et le Java Operator SDK que nous allons accompagner les participantes et participants de ce Workshop.

Nous allons développer une petite application Quarkus puis la packager et la déployer grâce au développement de l'opérateur. Pour terminer, nous automatiserons la partie opérationnelle pour que cette application fonctionne à la perfection et de manière robuste. Tout ceci sans quitter Java et Quarkus !

Nul besoin d'être un expert en Quarkus ou Kubernetes pour suivre le lab, aimer coder et connaître les bases de Java suffit largement. Vous n'aurez pas non plus besoin d'installer quoi ce ce soit sur la machine, un simple navigateur et le tour est joué grâce à la puissance de GitPod.

A la sortie de ce workshop non seulement le monde des opérateurs n'aura plus de secret pour toi, mais en plus tu en auras développé un !

L'architecture d'un logiciel, c'est le résultat d'un ensemble de contraintes fonctionnelles et techniques.
Lors de cette université, nous allons travailler sur le livrable classique de l'architecte : le diagramme d'architecture. Nous allons voir à travers des ateliers participatifs en quoi ce diagramme peut être insuffisant, et comment l'améliorer à la fois en rapidité d'écriture, en qualité de compréhension, et en capacité à décrire les différents aspects liés à l'architecture d'un logiciel.
Venez avec vos stickers, vos ordinateurs (avec Docker installé), les ateliers utiliseront à la fois des supports papier et des supports informatiques

Zones sans réseau, sites pas accessibles, télécommandes infernales … saviez-vous que 66% des utilisateurs sont exclus de vos dispositifs ?

Vous voulez vivre dans un monde où les portes s’ouvrent dans le sens où elles sont censées s’ouvrir ? Où vos parents sont autonomes pour refaire leur carte grise en ligne ? Où (folie !) un site se charge en moins de 25 secondes même avec une mauvaise connexion ?

Suivez-nous pour un tour d’horizon anti-exclusion : accessibilité, technique, complexité et contenu !

Vous avez sous la main des tonnes de documents Open Office, Microsoft Office, PDF voire des images... et vous aimeriez être capable de chercher dans leurs meta-données et dans le contenu lui-même. Comment faire ? Surtout depuis l'annonce de la fin de Google Search Appliance.

Dans cette session, David expliquera comment Apache Tika peut fournir ce service et comment combiner cette fantastique librairie avec elasticsearch :

* Elasticsearch [ingest-attachment plugin](https://www.elastic.co/guide/en/elasticsearch/plugins/current/ingest-attachment.html)
* [FSCrawler](https://github.com/dadoonet/fscrawler)
* Connecteur [Workplace Search](https://www.elastic.co/workplace-search) pour FSCrawler afin de disposer sur étagère d'une interface utilisateur puissante pour vos documents.

Construire son architecture distribuée en micro-service n'est jamais chose facile, et nombreuses sont les équipes faisant face aux difficultés de ce type d'architecture complexe pourtant très prometteuse.

Dapr est un projet Open Source (bientôt incubé par la fondation CNCF) permettant de faciliter l'élaboration d'une architecture micro-service. Agissant comme une couche d'abstraction applicatives, Dapr expose des mécanismes généraux tels que la gestion d'état ou les pub/sub via des canaux de communication standard. L'objectif est de simplifier la conception d'application en micro-service, peu importe la technologie utilisée (Node, Go, .NET, React ...)

Nous verrons dans cette session différentes architectures possibles avec Dapr, et quelques démo notamment avec Kubernetes permettant de faciliter l'orchestration des microservices.

**Format** : Talk

**Category** : Frontend

## Qui est l'audience ?

Cette présentation s'adresse aux développeurs frontend avec une première expérience conséquente sur le framework Angular (c'est-à-dire un niveau intermédiaire - 2 ou 3 années d'expérience sur Angular).

L'objectif sera de motiver les développeurs présents lors de la présentation à investir du temps pour monter en compétences sur RxJS, en présentant les avantages que peut représenter l'utilisation de la programmation réactive pour leurs projets et leur carrière.

## De quoi allez vous parler ?

La présentation sera focalisée sur l'utilisation concrète de RxJS au sein d'un projet Angular, au travers de 3 cas d'implémentation courants.
Pour chaque implémentation, nous présenterons un comparatif avec et sans la réactivité.

Voici une version globale de ce que nous présenterons :

### Introduction : Avez-vous le problème que résout RxJS ?

Pour beaucoup de développeurs juniors, RxJS est une technologie étrange, imposée par les créateurs d'Angular dans le framework.

Mais plutôt que de subir cette décision de la Team Angular, il faut rappeler que RxJS permet de faire bien plus que des requêtes HTTP.

L'objectif sera donc de se mettre d'accord sur le problème que RxJS résout : la complexité dans la base de code.

Nous commencerons donc par définir la complexité comme la somme de 3 composantes :

- Un état partagé et mutable. (Shared Mutable State)
- La circulation des données. (Data Flow)
- Le volume de code. (Code Volume)

Nous verrons comment RxJS permet d'adresser efficacement ces 3 composantes de la complexité.

### Partie 1 : 100 opérateurs RxJS en 10 minutes

Un des obstacles principal à l'apprentissage de RxJS est le nombre impressionnant d'opérateurs mis à disposition par la librarie (_plus de 100 !_)

L'objectif sera donc de rendre l'utilisation de ces opérateurs aussi digeste et intuitive que les méthodes utilisées pour le traitement d'un tableau : `map`, `filter` et `reduce`.

Nous verrons que les +100 opérateurs de RxJS peuvent être classés en 4 catégories simples :

- **Création** : _of, fromEvent, interval, timer, combineLatest, forkJoin..._
- **Transformation** : _map, switchMap, mergeMap, concatMap, bufferCount..._
- **Filtrage** : _debounce, throttle, filter, distinctUntilChanged..._
- **Calcul** : _reduce, scan, count, max..._

Pour chacune des catégories, nous verrons qu'il existe plusieurs opérateurs, car RxJS s'occupe de gèrer la dimension du temps en plus d'un simple tableau.

Cette dimension supplémentaire à l'air d'ajouter de la complexité a priori.
Mais cela permet de gérer l'asynchronicité dans notre code, de manière élégante et déclarative.

### Partie 2 : Résoudre des problèmes de la "vraie" vie avec RxJS

Les exemples donnés dans les tutoriels ont toujours l'air d'un monde "enchanteur", que les développeurs n'arrivent pas à appliquer concrètement dans la vraie vie par la suite...

Nous effectuerons 3 ateliers qui seront tous liés à un même _requirement_ d'un client fictif, dans Jira. Nous traverserons 3 couches logicielles du même _requirement_, mais en appliquant la programmation réactive à chaque fois :

**Couche de présentation** (Presentational Layer)

Exemple de gestion réactive de la vue dans le cadre d'un formulaire :
_combineLatest, fromEvent, debounce..._

**Gestion de l'état** (State Management)

Exemple de gestion réactive de l'état impacté par le formulaire précédent:
_BehaviorSubject, scan, next(), seletcors & async..._

**Couche d'accès aux données** (Data Layer)

Exemple de gestion réactive de l'accès aux données depuis un serveur distant :
_Requêtes HTTP & caching (HttpClientModule, catchError, timeout, map & shareReplay), Stratégies de mapping asynchrone (concatMap/mergeMap/switchMap/exhaustMap)_

### Partie 3 : Comment convaincre Mr. Promise et Mr. Fetch API d'utiliser RxJS ?

Une fois que l'on a découvert une nouvelle technologie et que l'on est capable de l'utiliser, il reste le plus dur...
Convaincre ses collègues de changer leurs habitudes pour travailler d'une nouvelle façon.

L'objectif de cette troisième partie sera donc de convaincre le reste de son équipe de se mettre à la réactivité.

Nous présenterons un framework simple qui permet d'expliquer rapidement aux autres membres de son équipe comment utiliser RxJS au quotidien.
Nous avons appelé ce framework : **"Golden River, Muddy River & Golden Road"**.

1. **Golden River** : Quel est le flux idéal que l'on veut obtenir en sortie ? Celui qui contient directement la réponse attendue ?
2. **Muddy River** : Quels flux nous avons déjà à notre disposition ? (_Cf Partie 1: Opérateurs de création_)
3. **Golden Road** : Quels opérateurs appliquer pour atteindre la Golden River à partir de la Muddy River ? (_Cf Partie 2: Opérateurs de transformation, filtrage et calcul_)

### Ouverture, Questions & Réponses

Ouverture : Rappelez que la programmation réactive avec RxJS est un paradigme de programmation qui peut-être utilisé en dehors d'Angular. (Notamment dans les autres frameworks frontend React & VueJS)

Question & Réponses : Répondre aux objections éventuelles et autres questions ouvertes.

## Comment aller vous en parler ?

Le déroulement de la présentation sera un talk plutôt classique, composé principalement de slides et de questions au public tout au long de la présentation.

1. Slides épurés et imagés pour se concentrer sur les explications de l'orateur.
2. Capitaliser sur la création de contenu "online" : c'est un format dans lequel l'attention de l'audience est une ressource rare. Nous essayerons donc de reprendre la même structure de contenu pour ne pas ennuyer l'audience (_présenter une histoire/anectode, donner des exemples concrets, montrer des captures d'écran_).
3. Pas de live coding prévu : pour un premier talk en présentiel devant une audience large, nous trouvons l'exercice déjà suffisamment exigeant.

More than 15 million Java developers are currently working to realize business requirements and spend a ton of time and effort to optimize the application performance for a variety of workloads (e.g., Web, Mobile, AI/ML, Edge) in the cloud. A big issue for the developers is to adopt a new language programming or runtimes over Java due to the lack of compatibility with Kubernetes.

This session will walk you through how developers can scaffold a Java project from scratch and then build it as a Kubernetes Native application that allows you to have a tiny low memory footprint and milliseconds startup time. You can also continue testing and debugging the application while it’s already deployed to the remote Kubernetes, same as the local developer experiences of inner loop development.

Est-ce que Firebase vous dit quelque chose ? Vous en avez sûrement entendu parlé et vous l'avez peut-être déjà utilisé, et pour le coup, c'est normal ! Voilà maintenant plusieurs années que de nombreux développeurs l'utilisent pour faciliter la création de back-end scalable et performant.

Mais avez-vous déjà entendu parler d'Appwrite ❓

Peut importe votre réponse, venez découvrir avec nous le duel entre Appwrite la jeune solution open-source et Firebase la flamme de Google 🥊

**Comment se passe l'écriture des tests JS pour toi ?**

- Tu changes tes tests dès que tu changes un composant ?

- Tu n'arrives plus à lire tes tests après 6 mois de développement ?

- Tu voudrais tester l'accessibilité de ton application mais tu ne sais pas comment ?

Pour te faciliter la vie, une librairie fut forgée par Kent C. Dott pour abstraire toutes les autres : [Testing Library](https://testing-library.com/) va t'aider à écrire des tests de meilleure qualité quelque soit ton framework.

Nous te proposons un tour d'horizon de l'API de cette librairie, avec des exemples de code, pour comprendre en quoi elle se distingue des autres.

**Qui sait, petit hobbit jouflu🦶, peut être que va finir par aimer écrire des tests ?**

Le Domain Driven Design est sur toutes les lèvres. Silver bullet ultime, distributeur à buzzwords, à croire que si à ta troisième levée de fonds tu ne fais pas du DDD, t’as raté ta start up. Mais par quoi commencer pour en tirer de la valeur rapidement ?

Et si la réponse n’était pas dans ses agrégats, value-objects, domain events et autres patterns tactiques populaires mais plutôt dans compréhension du métier ? Cela tombe bien car le DDD offre des outils qui permettent de s’approprier le métier afin de le modéliser correctement.

Découvrons ensemble les patterns stratégiques - la partie la plus importante du Domain-Driven Design - qui vous offriront de meilleurs retours sur investissement. Cela vous permettra d’adopter en douceur cette philosophie, loin de la hype et des difficultés techniques.

Combien d'entre-vous se sont déjà retrouvés à devoir analyser un bug, voire intervenir en astreinte et ne pas comprendre pourquoi ça a planté ?
Qui s'est déjà demandé si la ligne de log qu'iel est en train d'écrire relève du debug, de l'info ou autre ?
Qui a déjà du laisser son application en niveau de log maximal sans quoi aucune analyse n'est possible ?

Je vous propose aujourd'hui de vous donner quelques pistes pour soigner vos traces d'exécution, issues de mon expérience dans l'industrie du paiement sur autoroute.

---

Il s'agira d'une présentation "classique" avec slides.
Le sujet ouvert à tous niveaux et langages car je vais présenter ici des principes assez généraux, avec quelques exemples.

L'utilisation d'un store au *pattern Flux* est de nos jours choses courantes dans les applications front, ils font même souvent parti de template de création d'un nouveau projet. Néanmoins depuis quelques années, cette domination est remise en question. En effet, elle est souvent accompagnée d'une **complexité** et d'un coup d'entrée sur le code élevé, d'une **maintenance pas évidente** et d'un **boilerplate** important pour ne pas faire grand chose : charger une donnée avec un état de loading, et une gestion de l'erreur.

C'est ici que [TanStack Query](https://tanstack.com/query/v4) intervient, cet outil, cette lib, vous permet de simplement wrapper vos appels réseaux et d'avoir toute la gestion du loading, de l'erreur, de retry, du cache à travers les différents composants, bref de faire tout ce que vous écrivez actuellement dans votre store. TanStack Query vient dans le sillage des hooks, la lib s'utilise donc simplement avec un appel qui vous garantir une maintenance simple, une grande lisibilité et une robustesse à toute épreuve.

Que vous jouiez avec **React**, avec **Vue** (bravo vous êtes les meilleurs), avec **Svelte** ou **Angular** bientôt, cette lib est disponible dès maintenant. Je vous propose de vous la faire découvrir à travers un **live coding** dans lequel on transformera un store en un hook avec TanStack Query, en React et peut être même en Vue si on a le temps.

Vous maintenez des interfaces synchronizées entre votre back et votre front ? c'est lourd non ?

Peut-être avez vous besoin d'une étape de génération lors d'un changement de modèle de données de vos API's ?

Le saviez-vous ? : on peut aujourd'hui se passer de tout cela.

Découvrez une stack technique utilisant la puissance de typescript au service de l'expérience développeur et de la simplicité:

- __tRPC__ pour une API et son client sans schémas ni génération de code.
- __prisma__ pour un ORM supportant de nombreuses bases de données et orienté typescript first.

Il était une fois, dans une célèbre manufacture de pneus 🏭, une grande volonté de remplacer son orchestrateur supply chain et logistique 🚚. Le chef d'orchestre étant épuisé, il fallait le remplacer: et pourquoi pas par un joli ballet 🤔 ?

Ayant choisi ses nouveaux atouts, kafka et kafka streams, plongez dans l'aventure de notre équipe, ultra motivée, pour passer d'un logiciel orchestré à des chorégraphies de micro services bien rôdées ✨.
Sur un nouveau tempo 🥁, venez découvrir comment elle a pu accorder un rythme de batch quotidien voir hebdo avec des flux continus et instantanés d'une architecture event driven.
Mais aussi, venez apprendre de nos fausses notes et nos pas maladroits pour passer d'un monolith figé à plusieurs centaines de micro-services survoltés 🧨.


Fort de notre histoire, vous repartirez avec la stratégie qui nous a permis :

• la coordination harmonieuse de plus de 200 micro services kafka streams sur kubernetes tanzu,
• l'utilisation de 250 objets kafka connects pour discuter avec nos applications legacies,
• les points d'attention à garder en tête lors du passage d'un écosystème cadencé dans une base de données à un logiciel "event management" basé sur 1000 topics kafka

Vos applicatifs sont un peu ternes ? Transformez votre S.I en S.I.G en ajoutant une dimension géographique et cartographique. Que ce soit pour enrichir fonctionnellement vos applicatifs ou vos tableaux de bords, le S.I.G à plusieurs cordes à son arc.

Dans ce talk introductif vous découvrirez que les cartes ne se limitent pas qu'à Google Maps et que de nombreux outils (dont beaucoup open source !) existent pour proposer à vos utilisateurs et décideurs des cartes et web services à forte valeur ajoutée.

Si les termes fond de plan, vector tile, géocodage ne vous parlent pas, si vous voulez savoir comment un jeu comme Pokémon Go est possible ou tout simplement créer votre première carte alors ce talk sera votre getting started à ce vaste domaine qu'est celui de la carto.

Slides, démo, bonus, disponibles ici : https://github.com/MarcAlx/snowcamp.io-2023-intro-carto

J'ai eu l'occasion de mettre en œuvre :
- 4 solutions techniques différentes de data streaming (Apache Nifi, Apache Flink, Apache Spark Streaming et Apache Kafka Streams)
- 3 solutions de stockage de forte volumétrie (Apache Cassandra, TimescaleDB et Oracle DB)
- sur 3 projets différents de télécollecte IoT et de traitements de données Big Data.

Cela représente 8 ans de recul sur le traitement de données de forte volumétrie. Cette expérience s'est construite "grâce" à des dizaines de problèmes de performances, de cohérence des données, d'engorgement de nos systèmes distribués... J'ai donc de belles histoires techniques à vous raconter sur le pire et le meilleur de ces différentes solutions. Vous voulez savoir quelle est la meilleure et celle que je vous recommande ? Je suis sûr que vous connaissez la réponse courte "ça dépend". Pour la réponse longue, il faudra venir me voir...

Ces derniers temps, quand on pense à l'Infrastructure as Code (IaC), un outil semble se démarquer et est devenu un standard de facto : Terraform.

Avec Terraform, vous pouvez facilement créer, modifier et versionner l'ensemble de votre infrastructure en utilisant des *providers* natifs à Terraform ou des *providers* personnalisés.

Mais parfois, il n'y a pas de *provider* pour l'infrastructure que vous voulez utiliser, pas même un petit bout de code sans aucune référence dans un coin perdu d'Internet. La seule chose que l'infrastructure propose, c'est une API REST. Que pouvez-vous faire ? Revenir aux opérations manuelles ? Créer vos propres scripts bash pour piloter vos infras ?

Dans cette conférence, Horacio et Aurélie vous montreront, étape par étape, comment passer d'une API d'infrastructure à un *provider* Terraform entièrement fonctionnel mais léger. En prenant comme base une API REST, ils expliqueront les bases de la création du *provider*, donneront quelques conseils sur la façon de faire une architecture du *provider* simple mais efficace et vous montreront le code en action.

Vont-ils réussir cette nouvelle mission ? :-D

On dit parfois que tous les écosystèmes se valent, et qu'à partir du moment où un développeur maîtrise les concepts, il n'aura pas de soucis à les mettre en oeuvre...

Assez adepte du modèle hexagonale, de la clean architecture, et des concepts Domain Driven Design (DDD pour les intimes), Nicolas à poussé cette expérience pour proposer une API REST dans un contexte Javascript.

Est-ce que c'est simple ?

Est-ce que c'est fait pour ?

Est-ce que c'est une bonne idée ?

Spoiler normand: Peut-être que oui, peut être que non ... Ça dépend !

Venez découvrir les étapes de cette expérimentation, les points forts et les points faibles, ainsi que ce qui peut poser problème dans l'implémentation d'un modèle hexagonale dans l'écosystème NodeJS. Mais ne vous inquiétez pas, il existe quelques outils qui peuvent nous aider....

Avez-vous déjà entendu parler du terme "AI on edge" ? Il s'agit du déploiement d'applications d'IA sur des appareils situés dans le monde physique.
Les avantages ? Moins de latence, plus de sécurité, d'efficacité et surtout de la proximité ! Aujourd'hui, il devient donc de plus en plus important de pouvoir déployer des modèles d'IA capables d'inférer en temps réel.

La vision par ordinateur est particulièrement concernée de par sa progression rapide et son utilisation dans de nombreux domaines : automobile, médical, commerce, ... Elle regroupe de nombreuses techniques comme la classification d'images, la segmentation d'images ou encore la détection d'objets.

Cette dernière permet d'identifier et de localiser les différents objets sur une image ou sur une vidéo. Un célèbre algorithme de détection d'objets, connu pour son fonctionnement rapide, se nomme YOLOv7.

Dans ce talk, nous verrons comment déployer un modèle YOLOv7 pour la détection d'objets sur une carte Raspberry Pi 4.

Pour cela, nous nous intéresserons à l'entraînement et au test d'un modèle YOLOv7 au sein d'un Notebook Jupyter. Nous convertirons ensuite notre modèle pour pouvoir le déployer et faire de l'inférence sur Raspberry Pi.
La finalité ? Un outil de détection d'objets en temps réel à portée de main.

Alors, on embarque ?

Aujourd’hui l’intérêt des chaines de CI/CD n’est plus à démontrer ; elles permettent l’automatisation de nombreuses tâches allant du build d’une application à son déploiement sur des environnements Cloud ou OnPremise gérées par l’entreprise. Mais qu’en est-il lorsque vous déployez / maintenez cette même application chez plusieurs de vos clients et sur des environnements à accès restreint ?

Dans ce retour d’expérience, vous verrez comment nous avons contourné ce problème pour déployer une même application sur plusieurs clusters **Kubernetes** cible sur lesquels nous n'avions pas la main (qu’ils soient OnPremise ou managés) à l’aide de **FluxCD**.

Nous évoquerons les points positifs, négatifs et de vigilance que nous avons pu identifier lors de la mise en place de cet outil dans une démarche **GitOps**.

Certaines équipes hésitent ou ne mettent pas en place de tests end-to-end.
"Trop dur à mettre en place" "Tests difficiles à maintenir" "Perte d'argent et de temps"

Dans cette conférence, je vous propose de partir à la découverte de Playwright. Un nouvel outil Microsoft, rapide, fiable et complet, qui va probablement changer vos aprioris et appréhensions sur les tests sur navigateurs.

À travers live-coding, démos et exemples, nous verrons comment créer des tests robustes. Nous évoquerons aussi les performances, les limitations à prendre en compte, l'outillage ou encore comment débugger, même après coup.

Venez découvrir le futur des tests end-to-end !

Distribution, haute tolérance à la faute, temps réel, et déploiement avec zéro secondes d'interruption sont les promesses que Erricson se fait, pour ses réseaux de téléphonie, dès 1986 avec le language Erlang et l'Open Telecom Platform. 36 ans plus tard, l'industrie logicielle cherche toujours de nouvelles approches pour assurer la haute disponibilité et le déploiement continu de ses applications . Et si une solution était déjà sous nos yeux ? Construit sur l'écosystème Erlang, le language Elixir, à partir de 2011, propose un nouvel écosystème moderne grandissant dans le développement web, le streaming, l'analyse de données, le machine learning,...

Si apprendre à lancer 100.000 processus en parallèle ne vous fait pas peur, accompagnez moi, pour un tour complet du language Elixir et comprendre pourquoi les forces d'un language et de son écosystème aident à adopter les principes d 'architecture logicielle qui nous sont chers comme le Domain-Driven Design, les monolithes ou les microservices.

•  Slides en PDF et en Reveal.js: https://github.com/mjanv/snowcamp-2023
•  Code source de la démo: https://github.com/mjanv/gameoflife

J'ai rejoint ma nouvelle équipe il y a 6 mois, avec une appréhension. Comment allais-je vivre les revues de code par des collègues que je ne connais pas encore ? Incompréhensions, malentendus : la communication écrite rend cet exercice très délicat. Vous avez été blessé-e par un commentaire ? Etait-il vraiment mal intentionné ? Vous avez blessé quelqu'un sans le vouloir, à cause d'une tournure maladroite ?

J'ai découvert un cadre qui m'a permis de me sentir bien accueillie dès mon arrivée. En adoptant une posture et une convention bien adaptée, on peut largement diminuer le risque de mal se comprendre. Non seulement on communique mieux, mais on améliore la qualité globale du projet.

Vous n'aurez plus aucune raison de souffrir !

A l'heure de la virtualisation à gogo où nous utilisons des machines virtuelles et conteneurs à tour de bras sur nos machines de guerre, rappelons-nous que cette pratique, l'émulation de matériel, est issue de la mode du retro-computing qui fit fureur à la fin des années 90, dont le seul but était de faire revivre les ordinosaures des années 70 et 80 pour une poignée de passionnés ... et aussi afin de sauvegarder un patrimoine technologique des débuts héroïques de l'informatique.

Mais d'ailleurs ... Comment développe-t-on un émulateur d'ordinateur ?

Ce talk va nous plonger dans les méandres de l'émulation et permettra de faire la lumière sur l'exigence de cette pratique ... Du reverse-engineering à la simulation de matériel, nous découvrirons le parcours du combattant du codeur et différentes techniques pour émuler correctement une machine, en prenant notamment comme exemple mon projet d'émulateur d'Amstrad CPC, « XCPC ».

Ce talk présente des principes/recommandations pour concevoir des URLs d'une API REST. Au travers du nommage, c'est la conception même de votre API qui est exposée.
En appliquant ces principes, vous d'améliorerez la DX (Developer eXperience) lors de l'utilisation de votre API en maximisant l'affordance (Evitez le RTFM ou comment minimisez la doc parce que de toute façon, le developer ne l'a lit pas ...).

Le contenu :
- Introduction : Pourquoi se soucier du nommage dans une API?
- Resource vs fonction : Avoir une approche ressource dans le nommage de son API: Pourquoi et Comment ?
- Granularité d'API : C'est quoi la bonne taille ... de votre ressource.
- Nommage : tiret, undescore ... ou Camel case ? mais aussi le choix des mots et KISS
- Versioning : Quand et comment
- Tri, Filtre, Recherche : Eviter le NIH (Not Invented Here) en utilisant les conventions bien établies
- Gestion des erreurs : Et si on repartait déjà de HTTP

Je présente aussi ce que font les géants du web et on verra qu'ils ne sont toujours d'accord entre eux.

A la fin vous aurez les clés pour construire une API qui respecte la philosophie REST et qui soit facilement compréhensible par les développeurs.

Le platform engineering est la discipline consistant à architecturer et construire des chaînes d'outils et des processus permettant l'autonomie des équipes de développement à l'ère du cloud natif.
De nos jours, les entreprises pratiquant l’approche DevOps ont besoin que leurs équipes puissent gérer l’infrastructure de manière autonome. Afin de garantir la maintenabilité de l’infrastructure et de répondre aux besoins de flexibilité de leurs clients internes, les équipes SRE fournissent souvent des librairies construites sur des langages respectant les principes clés que sont l’idempotence et l’immutabilité. Disons clairement les choses, Ansible, Terraform et leurs confrères sont souvent au centre de l’affaire. Avec l’avènement de Kubernetes, de nouvelles méthodes s’appuyant sur les fondements de l’orchestrateur apparaissent.
Dans cette session, nous ferons un tour de l’état de l’art du "Platform Engineering" et montrerons comment ces pratique et ces outils émergents, couplés à une approche GitOps peuvent constituer un choix stratégique pour votre entreprise.

Les tests d'accessibilités web : on en voit trop peu dans nos chaînes de CI/CD et pourtant, il est possible de faire pas mal de choses ! Les outils et techniques pour automatiser des tests d'accessibilité sont multiples mais relativement méconnus des développeurs web. Que pouvons-nous tester, et comment ? Etudions tout cela ensemble, regardons comment intégrer ces tests dans nos pipelines (Gitlab CI, GitHub Actions, ...).

Bonne nouvelle, mon data-scientist a fini de travailler sur son modèle. Celui-ci donne les résultats attendus, il est sérialisé comme il faut... il ne reste plus qu'à le déployer!
Oui, mais comment ?

Dans cette présentation, vous verrez un exemple de conception pas à pas d'une application dédiée au déploiement de modèles d'IA avec une api HTTP very low latency. Nous partirons du "modèle" comme une brique boite noire et construirons l'architecture du système autour. Nous verrons notamment :

- La différence entre le preprocessing fait par le data scientist en mode traitement batch et le preprocessing en mode traitement au fil de l'eau nécessaire pour le déploiement
- Des astuces pour améliorer la latence
- Des architectures possibles pour gérer l'ingestion des données
- … et d'autres idées pour passer de la data science en POC à un vrai déploiement en production.

A la fin de ce talk, vous aurez les clefs pour que la conception d'une telle application se passe de façon sereine, et sans mauvaise surprise une fois la mise en production faite. Peut-être que nous arriverons même à réconcilier data science et data engineering ?

De l’analytique temps réel pour vos utilisateurs, à la demande, sur des données tout juste intégrées dans le système, à l'échelle . Vous pouvez en voir des exemples lorsque vous regardez votre flux d’activité sur Linkedin ou que vous regardez un dashboard de livraison de votre plat favori.

Pour mettre à disposition de vos utilisateurs ce genre d’analyses temps réels, de nouveaux outils spécialisés émergent comme Apache Pinot.
Cette base de données utilisée par des acteurs comme Linkedin, Stripe et Uber sur des datasets de centaines de TB pourrait bien être la solution que vous attendiez.

Venez découvrir comment mettre en place et utiliser Apache Pinot. Venez mettre de la donnée dans votre vin.

Pourquoi développer des applications natives pour systèmes d'exploitation bureau est couteux et complexe? Ne pourrait-on pas simplement utiliser les technologies du web pour créer des applications de bureau qui rivalisent avec les applications traditionnelles?

Dans cette session, nous verrons comment les PWAs sont en train de révolutionner la manière de développer et de distribuer des applications extrêmement poussées, y compris sur des systèmes d'exploitation bureau.

Au programme: des demos, du code, et des explications techniques pour apprendre comment créer des expériences utilisateurs dignes de véritables applications de bureau. Vous ressortirez de cette session motives et impatients d'utiliser les dernières fonctionnalités du web pour créer votre propre appli.

La conception d'une plateforme est toujours délicate à initier.

Comment démarrer? Quelle est la démarche à adopter pour concevoir une architecture? Quel est le modèle à appliquer: event streaming, orchestration ou chorégraphie?
Au travers d'un besoin utilisateur, nous prendrons notre "casquette" d'architecte et déroulerons devant vous une étude pour une toute nouvelle plateforme "Donut @ Home".

Après avoir analysé le besoin, confrontés nos idées et convictions devant vous, nous choisirons, parmi toutes les solutions possibles, quelle est la *"moins pire"*.

Nous vous solliciterons pour valider notre conception et les exemples d'implémentation possibles.

A la fin de cette présentation, vous aurez des clés pour penser et démarrer les études de vos architectures en toute sérénité (ou presque).

Le machine learning, ce terme est sur toutes les lèvres, on en entend parler du soir au matin. Tellement que son intérêt semble plutôt d’être la carte joker pour gagner au buzzword bingo, mais il y a bien certaines problématiques où sortir cette carte fait sens : l’accessibilité !

Et oui, malgré les nouveautés technologiques, beaucoup de gens à l'heure actuelle sont exclus de notre univers numérique à cause d’un défaut de vision, d’audition, de diction, de langage, etc. Aujourd’hui, les avancées en terme de machine learning sur la compréhension de la parole, du texte et de ce qui est contenu dans les images et vidéos, sont telles qu’elles permettent de rendre beaucoup plus accessible les contenus numériques. Mais savons nous comment cela fonctionne et quelles en sont les limites ?

Dans cette présentation, parsemée d'humour et de fun, Aurélie et Guillaume, vous montreront, au travers de démos et d’exemples concrets, comment l’accessibilité peut bénéficier des avancées du machine learning.

Last week, you spend the last 2 days writing plenty of tests. Your code coverage was 100% so you thought you could safely leave on a weekend ✈️🏖️

But on Monday, your inbox is flooded with new bug reports.
What happened!? What did you miss?

In this talk, we present Mutation testing which is a technique to evaluate the quality of tests beyond the number of lines tested. Mutation testing is based on creating a changed copy of the code to ensure a software test suite is able to detect the changes.

How do we create Mutation tests? How does it work? What are the advantages and drawbacks of Mutation tests?
All these questions will be answered with a demo in this talk.

Come and discover what Mutation testing is and how can we implement it to ensure the quality of our test suites.

Vous avez déjà eu envie de générer des vidéos ... ?

Vous ne trouvez pas un outil pas cher, facile à prendre en main et pas limiter dans les possibilités ?

Vous avez des bases en HTML, CSS et Javascript ?

**Remotion est fait pour vous !** 🫵🏼

Remotion est une lib open source publiée en 2019, qui permet la génération de gif, d'animations, de vidéos de manière programmatique, à partir de composant React !
Nous allons vous partager notre aventure de création de trailer vidéo dans le contexte des plateformes de streaming sur lesquels nous travaillons chez Bedrock. Nostalgique des programmes du début des années 2000, on a essayé de reproduire quelques bandes d'annonces pour vous rappelez des souvenirs et vous montrer à quel point c'est facile !

Installez-vous et préparez vos pop-corn la séance va commencer ! 🍿

Rust est en passe de devenir l’un des langages les plus influents des prochaines décennies : intégré au kernel Linux tout récemment, peu énergivore à l’exécution, langage préféré des développeurs pour la septième année selon StackOverflow, etc. Cet engouement est-il véritablement justifié ? Quelles sont les fonctionnalités qui en font un langage agréable à utiliser, et à l’inverse, quels sont ses douleurs ?
Netwo a fait le choix il y a 2 ans d’utiliser Rust.

Que peut-on en retenir vis-à-vis de :

• la montée en compétence des développeurs
• l’utilisation du langage au quotidien
• le comportement des applications en production

Nous vous proposons donc un retour d’expérience de son utilisation dans le cadre d’un SaaS web. Nous insisterons sur les sujets qui, à nos yeux, font la force de ce langage.
Aucune compétence Rust préalable n’est nécessaire. Nous expliquerons les concepts par des exemples de code suffisamment simples pour être compris par tous.

Au cours de ces dernières années, l'IA à fait beaucoup de bruit dans le monde de l'informatique, que ce soit dans le milieu de la recherche, du médical, du jeux vidéo etc…
Mais depuis quelques années, l’IA commence même à être présente dans des domaines qui étaient jusqu’alors réservé aux humains, le principal exemple étant l’Art, tout en devenant de plus en plus accessible.

Durant ce talk de 45 minutes, je vais faire un état de l’art sur l’avancée de l’IA ces dernières années en m’appuyant principalement sur le cas de la génération d’image assistée par IA. Je présenterais comment tout a commencé, comment fonctionnent les derniers modèles et je traiterai également des différentes problématiques liés au développement de l’IA.

Aucune connaissance sur le sujet n'est nécessaire pour assister à ce talk, il est pensé pour être ouvert au plus de monde possible :)

Le code auquel nous sommes pour la plupart confronté.e.s comporte beaucoup d’informations implicites (erreurs, exceptions, nullables, …). Celles-ci se montrent problématiques car elles nécessitent des connaissances poussées de la codebase et génèrent une charge cognitive supplémentaire. Malheureusement, tout ceci augmente la probabilité que les développeur.euse.s fassent des erreurs.
Au cours de ce talk, exemples à l’appui, nous vous montrerons comment rendre plus explicites ces comportements cachés à l’aide de votre système de types. Nous mettrons ensuite en lumière les problématiques qui en découlent et comment les résoudre.

Au cours de ce talk, nous allons présenter :

• les informations qui peuvent exister de façon implicite dans une codebase
• comment rendre ces comportements plus explicites avec des types (Option<>, Result<>, etc)
• highlight des problématiques de composition générés par ces types
• exemple de composition similaire et mieux maîtrisé par les développeur.euse.s : les listes avec les map, flatmap, etc
• Railway programming : transposition de ces concepts sur le Option<> et le Result<>
• bénéfices et inconvénients : quand l’utiliser et quand ne pas l’utiliser (il nous semble important de souligner que ça n’est pas une silver bullet)

Par défaut, nos langages de prédilection sont C# & F#, nous pouvons tout de même envisager d’autres langages pour nos exemples si les organisateurs pensent que cela serait plus adapté à l'audience.

La programmation asynchrone et non-bloquante nous permet de tirer le meilleur parti du matériel dont nous disposons. Grâce à elle, nous pouvons augmenter la densité de déploiement et, de ce fait, diminuer les coûts et le gaspillage des ressources. Les bénéfices sont marquants dans les architectures microservices, lorsque nous combinons différentes sources de données en transit sur le réseau. Dans leur boîte à outils, les développeurs Java disposent de clients HTTP réactifs, mais est-ce utile sans équivalent dans le monde SQL?

Nous allons explorer quelques solutions pour l'accès non-bloquant à une base de données relationnelle. Nous commencerons par JDBC comme contre-exemple, puis nous verrons comment utiliser Vert.x Reactive SQL Client. Enfin nous ferons connaissance avec l'ORM Hibernate Reactive. En tenant compte de leurs avantages et de leurs limitations, vous serez capables de faire vos choix entre compatibilité et efficacité, flexibilité ou productivité.

Ctrl + C, Ctrl + V ! dupliquer ou ne pas dupliquer ?

----------------
Plus d'information sur le sujet

Voir la présentation :  

----------------


`Ctrl+C` et `Ctrl+V `sont deux des raccourcis les plus utilisés par les développeurs, mais cela peut être la source de nombreuses erreurs Si vous êtes un développeur, vous avez probablement entendu la même chose à maintes reprises : éviter de dupliquer le code !

Mais qu'est-ce que cela signifie ? Quels sont les avantages de garder votre code aussi unique que possible ?

Alors pourquoi devriez-vous vous soucier de la quantité de duplication dans votre code ?

Dans cette présentation, nous allons explorer diverses techniques pour réduire la quantité de code dupliqué dans vos projets. Nous verrons comment appliquer ces techniques à différents types de développement : logique métier, front-end, le back-end ou même le CSS.

Bien qu'il existe plusieurs techniques pour éviter la duplication du code, nous verrons qu'il est parfois préférable de dupliquer votre code.

Ce n'est pas une personne, mais deux développeurs presque copiés/collés (jumeaux) qui vont venir vous parler de duplication de code. Je dirais même plus, on va vous parler de duplication de code !

-----

> Duplicated code is the root of all evil in software design. — Robert C. Martin

Intelligence Artificielle, Machine Learning, Deep Learning, ...
Ces termes on les entend tous les jours mais au final que représentent-ils et surtout comment développe-t-on des applications basées sur ces notions ?

Durant ce talk nous vous ferons découvrir le monde de la data et comment il est, avec les bons outils, facile de se lancer dans l'aventure de l'analyse de données et de la classification.

Ce talk permettra aux développeuses et développeurs de découvrir comment développer des applications apprenantes et montrera qu'il n'est pas nécessaire d'être un As du développement pour développer son propre algorithme de Machine Learning ou de Deep Learning.
Nous vous montrerons comment créer votre premier Notebook avec JupyterLab afin de vous accompagner dans vos premiers pas.
Ce sera l'occasion pour vous de plonger dans la découverte du monde sous-marin en développant un modèle permettant d'identifier et classifier les sons de mammifères marins.

Pour finir, nous verrons ensemble, avec [Streamlit](https://streamlit.io/), comment développer une application utilisant ce modèle.

La tendance à la dématérialisation et le déplacement des applications vers le cloud sont une évolution qui peut permettre d’améliorer l’impact carbone d’un grand nombre de secteurs et en particulier celui de l’Information, Communication et Télécommunications (ICT).

Passer au cloud est un moyen efficace pour “réduire” ses émissions en déportant l’impact du scope 2 vers le scope 3, qui est encore très peu pris en compte de manière légale. Tout ceci est néanmoins en train de changer, les législateurs étant en train de légiférer pour empêcher cette option commode de “greenwashing”.

Cependant, encore faudrait-il pouvoir être capable de mesurer de manière suffisamment précise ces émissions déportées! Difficile, de plus, d’agir sur quelque chose qu’on ne mesure pas. Pour toutes ces raisons, il est essentiel d’essayer de mettre en place des systèmes permettant de mesurer l’impact carbone des applications cloud.

Nous examinerons dans un premier temps le contexte de l’impact carbone du secteur ICT pour ensuite se confronter aux problématiques rencontrées pour mettre en place un tel système de mesure et finirons en examinant un exemple concret de solution en cours de développement.

Tu t’es déjà senti frustré·e par le CSS ? Que ce soit pour centrer les choses verticalement
ou utiliser des hacks magiques pour obtenir ce qu’on veut… soit on a le “gène CSS”, soit on ne l’a pas. Les devs qui aiment le CSS semblent plus être l’exception que la règle.

Mais n’aie pas peur ! Ce n’est pas une fatalité.

Après avoir formé des douzaines de développeurs à CSS sur les 5 dernières années, j’ai fini par comprendre ce qui n’allait fondamentalement pas avec le CSS. Et je suis prêt à te le partager. Au programme :

- une analyse d’où vient vraiment cette frustration
- des astuces actionnables pour level up rapidement son niveau en CSS
- comment apprendre les bons modèles mentaux pour intégrer des designs complexes

Qui sait ? Tu finiras peut-être même par aimer ça !

Découvrons ensemble les différentes façons existantes en 2023 pour organiser ses grosses applications frontends et plus particulièrement ses portails d'applications, de façon à éviter leur dépréciation précoce ou leur inmaintenabitilié.
Nous verrons dans un premier temps ce qu'il faut éviter. Puis dans un second temps, à travers des démos de code, nous verrons les structures suivantes :

• L'approche par librairies (npm).
• L'approche par monorepo (avec Nx).
• L'approche micro-frontend.

Pour chacune, nous évoquerons les avantages et inconvénients, ainsi que dans quel cas les utiliser.
Alors parlez ami, et entrez ;)

Je ne sais pas si vous connaissez le protocole RSA, mais il est fort à parier que vous l'utilisez au moins une centaine de fois par jour, par exemple en consultant des ressources via le protocole HTTPS. C'est un fait ! Ce protocole né en 1977 est LE standard de la cryptographie à clé publique utilisé aujourd'hui. C'est lui (ou un de ses petits frères) qui permet d'authentifier les certificats TLS et d'établir des clefs de chiffrement de manière sûre, pour vos communications quotidiennes. Malheureusement, ce protocole est en danger depuis l'existence de l'algorithme de Shor. En effet, Shor sait utiliser des ordinateurs quantiques pour casser les clefs de chiffrement produites par RSA, avec une facilité effrayante.

En Août 2016 l'institut de standardisation NIST prend les choses en main et organise un challenge pour établir des remplaçants de RSA, qui devront résister aux attaques quantiques. Le 5 Juillet 2022, le challenge est relevé ! Les protocoles Kyber, Dilithium, Falcon et Sphincs+ sont candidats à la standardisation. Il est alors temps de comprendre les enjeux de la cryptographie post-quantique, ainsi que le principe de chiffrement à base de réseaux euclidiens (traduit "lattice" en anglais).

Dans ce talk, je propose une vulgarisation qui vous permettra de comprendre le problème de la cryptographie post-quantique, ainsi que le chiffrement à base de réseau euclidien, qui semble en être la solution standardisée.