air - User contributions [en]

Projets 2022-2023

2023-03-15T22:31:05Z

Martin.Verrier:

<<[[Projets 2021-2022]] | [[Projets]] | [[Projets 2023-2024]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: Lundi 9 Janvier 2023 après midi à '''14h30 salle PG 39'''
* Soutenance à mi-parcours: Mardi 28 Février 2023 après midi à '''14h00 salle PG 39'''
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2022_2023. '''Cette fiche compte pour la note finale'''

* '''Votre code doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23''' , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** *Un ou plusieurs pour le code,* les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en français, la soutenance sera taire en français.

* '''Une section dans le rapport doit indiquer ce qui a été développé (LoC) et/ou testé.'''

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spécifiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [[Centipède]], Nicolas Palix, Didier Donsez
* 2. [[Dévelopement d’une application iOS/Android RTK NTrip]], Éric Sibert, Yves Pratter (pour les communautés OpenStreetMap et Centipède)
* 3. [[Reconnaissance de chants d'oiseau par réseaux de neurones embarqués avec TinyML]] (Attention c'est le meme projet que le projet 16 "Robin"), Didier Donsez
* 4. [[Développement d'extension de jeux sur DreamCast]], Matthieu Mallet (à confirmer)
* 5. [[Des polymères dans ton école, dans ton musée]], Vincent Mareau, Olivier Richard
* 6. [[Guidage autonome centimétrique de véhicules sur circuit]], Didier DONSEZ.
* 7. [[Géolocalisation intérieure centimétrique en Ultra Wide Band]], Didier DONSEZ.
* 8. Reprise du projet 21-22 [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 9. [[Paquets NIX pour Polytech]], Olivier Richard
* 10. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 11. [[Logiciel d'execution de commande à distance]]: Rust + tokio + grpc/tonic, Olivier Richard
* 12. [[Limitation des appels systèmes noyaux pour les systèmes de fichiers distribués]], Olivier Richard
* 13. [[Proof of Coverage LoRaWAN pour TTN, CampusIoT et Helium]], Didier Donsez, Olivier Alphand.
* 14. [[Jeux d'arcade pour table tactile de café]], Didier Donsez, Nicolas Palix.
* 15. [[Analyse et visualisation de données environnementales d’espèces envahissantes]], Thierry Tatoni et et Estelle Dumas (Institut Méditerranéen de Biodiversité et d'Ecologie)
* 16. [[Robin, la suite]] (Attention c'est le meme projet que le projet 3 "Chant d'oiseaux"), Didier Donsez
* 17. Poursuite projet 21-22 [[Portail pour gestionnaire de taches]](react, Typescript) ou reecriture en VueJS, Olivier Richard
* 18. Reprise du projet 21-22 [[Portail pour gestionnaire de taches]] avec [https://docs.streamlit.io Streamlit](Python), Olivier Richard
* 19. [[Portage d'Artiphonie en Godot 4]], Olivier Richard
* 20. [[Amélioration de la plateforme de prêt Matos de la fablab MASTIC]] Germain Lemasson
* 21. Portage Godot 3 ou 4 de [[TanksOfFreedom]], Nicolas Palix
* 22. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* 23. [[Faults In Linux]], Nicolas Palix
* 24. [[OsmAnd+Traffic]], Nicolas Palix
* 25. [[Géolocalisation dans une constellation de cubesats ou de pseudolites]], Didier DONSEZ, Olivier ALPHAND

{|class="wikitable alternance"
|+ Affectation des projets INFO4 22-23
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 2
| [[TODO]]
| BOUSQUET THOMAS,DECORSAIRE MATTEO,DELAS TANGUY,GRANDHOMME PAU
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/02/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [[TODO]]
| CHAOUACHE AKRAM,GHAMMAZ ALI,GLIM MOHAMED,THEVENON ESTEBA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/03/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [[TODO]]
| AVANTURIER AURELIE,GUYOT ROMAIN,SOLER LILIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/05/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[TODO]]
| CORREIA DE OLIVEIRA DIEGO,GALINIER CLEMENT,GALLIER LORIC,THOMAZO CORENTI
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/06/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[TODO]]
| BRUN SAMUEL,KEMGNE NASAH DARRYL JORDAN,LITHAUD ALEXANDRE,TYNDAL LUCA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/10/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 11
| [[TODO]]
| GOGUILLOT AMAURY,ISABELLE WILLIAM,JOUVE AXEL,PUCCI JEREM
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/11/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 13
| [[TODO]]
| COSTE AURELIEN,COURANT MATHIS,DUPONT ELISE,RIFFARD LON
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/13/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[TODO]]
| BOMPARD NOAH,BRACQUIER BENJAMIN,DUCROS VINCENT,KURKLU FIKRE
| Didier Donsez, Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/14/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [[TODO]]
| ENDEZOUMOU YANN,ETEUBOU EZEMGAN DUREL JUNIOR,GUERIN LOUISE,MACHENAUD FLORIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/15/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 17
| [[TODO]]
| BONFILS ANTOINE,CATTEAU PIERRICK,FERRARI JULIE
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/17/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 18
| [[TODO]]
| CHARRA ELOI,KHELIFI AHMED AZIZ,MAIDA LEA,MOUNIER DORIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/18/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[TODO]]
| ALLÈGRE VICTOR,PALMA ARTHUR, KINSKY MENDES LUIZ
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/19/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 21
| [[TODO]]
| FAILLA MAXIME,GRICOURT KILLIAN,LOPES THEO,MAUFRAND MICHELL
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/21/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 22
| [[TODO]]
| ABARNOU ELOISE,CAUCHY MARINE,LIMA LEITE JAMILE,PUECH LILIA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/22/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 26
| [[TODO]]
| GELEZ ANA,GRANGE MATHIS,MATHIEU LUCAS,ONGHENA EDGA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2022. Soutenance ?? Janvier 2023.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 22-23
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Le projet S10 est un projet en équipe qui se déroule en quasi-plein temps au début du semestre 10. Les équipes sont constituées de 2 à 4 élèves. Chaque équipe traite un sujet proposé par un porteur (enseignant de l'école, association ou entreprise externe à l'école). Le sujet est en général exploratoire . Chaque équipe est autonome dans son organisation. Les choix technologiques sont décidés par l'équipe en concertation avec le porteur. L'équipe rencontre régulièrement le porteur pour présenter les choix et rendre compte des avancements et des difficultés rencontrés. Le projet fait l'objet de 2 soutenances et d'un présentation d'un poster en anglais.

====Organisation====

Calendrier: 16/01 (8H30-12H00) au ??/03.

Convention des projets tutorés externes : Elise Didier.

Réunion de présentation et choix des sujets: 16/01 (9H00-12H00) (salle : voir ADE et distanciel Zoom pour les élèves et les porteurs de sujet)

Démarrage travail de groupe: dès les examens passés

Séances de Management de projets innovants (Responsables: Stéphanie Diligent et Emmanuelle Tréhoust): A voir dessus.

Soutenance à mi-parcours : 10/02/2022 13H30-17H30 (15 minutes par équipe).

Soutenance finale : 17/03/2022 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

Présentation posters (Responsable: Caroline West) : 16/03/2022 après-midi.

====Séances MPI====

Voir ADE qui fait foi.

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date: 10/02/2023 13H30-16H00. Salle 035.

Créneaux de 10 minutes. 5 minutes entre 2 créneaux.

Ordre de passage : 13H30 + (0H15 * (numero de groupe - 1)

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche

L'équipe présentera en 5-6 transparents en 7 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Prévoyez du temps pour les questions-réponses (3 minutes max).

Respectez bien les créneaux indiqués (par respect pour les autres équipes) et soyez présents un peu en avance dans la salle d'attente.

La présence des porteurs n'est pas obligatoire.

==== Soutenance finale S10 ====

Date provisoire: 17/03/2023 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 40 minutes par équipe: présentation (20 minutes), démonstration (10 minutes) et questions/réponses (10 minutes). 5 minutes de battement avec l'équipe suivante.

Les documents devront être en ligne sur le wiki (colonne Documents) la avant-veille (ie avant le 15/03/2021 23:59:59 CET) qui est aussi la veille des posters en anglais.

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

Votre fiche d'auto-évaluation doit être déposée sur [https://im2ag-moodle.univ-grenoble-alpes.fr/course/view.php?id=99 Moodle]

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil :
* 20+10 minutes c'est très court alors répétez la soutenance et votre démonstration auparavant !
* Prévoyez 1 ou 2 transparents pour présenter la démonstration.
* Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

====Planning soutenances====
=====Matin (Polytech Grenoble, Salle 257, 2ème étage)=====
* 08H30 Cinéma Project Manager
* 09H15 Evaluation en ligne
* 10H00 Visit360
* 10H45 Carte avalanches et neige
* 11H30 Fitsize

=====Après midi (Polytech Grenoble, Salle 257, 2ème étage)=====

* 12H45 Polytech SI
* 13H30 Mapillary RTK
* 14H15 Intégration LoRaWAN à la plateforme Domus
* 15H00 eCOM Suite
* 15H45 pause
* 16H15 Assistant Vocal avec ChatGPT

ADRESSE GEOGRAPHIQUE: Polytech Grenoble, 14, Place du Conseil National de la Résistance, 38400 Saint-Martin-d’Hères

=====After soutenance after COVID=====

Avant le COVID, il était traditionnel d'organiser un pot INFO5 dans la cafét de Polytech après les soutenances. Si vous êtes interessés, signalez votre envie d'organiser ce pot de fin de projet (et du début du stage).

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2022-2023
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[FitSize]]
| Clément NGUYEN (Chef de projet), Valentin DE OLIVEIRA, Sami IFAKIREN, Florian CHAPPAZ
| Fidèle Eya'a
| [[Suivi FitSize 2022-2023|Fiche de suivi]]
| [https://github.com/2022-2023-INFO5-FitSize/docs/blob/main/Rapport_Final.MD Rapport final] - [https://slides.com/clementnguyen/fitsize-2ba7fb Presentation finale FR] - [[Media:Rapport_Technique_FitSize_2022-2023.pdf|Rapport Technique]] - [[Media:Test infrastructures FitSize_2022-2023 Flyer.pdf|Flyer]] - [https://slides.com/clementnguyen/fitsize Presentation de mi-parcours] - [[Media:English_Poster_FitSize_2022-2023.pdf|Poster EN]] - [[Media:Pitch_FitSize_2022-2023.pdf|Pitch]]
| [https://github.com/2022-2023-INFO5-FitSize Dépot Git]
| [https://slides.com/clementnguyen/fitsize Presentation intermédiaire]
|-

!scope="row"| 2
| [[Outil de création de visite virtuelle de bâtiments avec placement d'information temps réel]]
| Justin NGUYEN (Chef de projet), Ayman FAGHLOUMI et Clara BERNERD
| Didier Donsez
| [[Suivi Outil de création de visite virtuelle de bâtiments avec placement d'information temps réel 2022-2023|Fiche de suivi]]
| [https://github.com/Visit360/docs/blob/main/Rapport_final.md Rapport final] - [[Media:Présentation_finale_VISIT360.pdf|Presentation finale FR]] - [[Media:Flyer_Visit360.pdf|Flyer]] - [[Media:Soutenance-intermédiaire-Visit360.pdf|Presentation de mi-parcours]] - [[Media:Final_poster_visit360.pdf|Poster EN]] - [[Media:Pitch_VISIT360_2022-2023.pdf|Pitch]]
| [https://github.com/Visit360 Dépôt Git]
| [[Media:Soutenance-intermédiaire-Visit360.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Carte neige et avalanches – Skitour.fr]]
| Eve Poitevin (Cheffe de projet), Julien Guignard, Thomas Bach et Thomas Fournier
| Jeroen Zijp (SkiTour)
| [[Suivi Studio Carte neige et avalanches – Skitour.fr - 2022-2023|Fiche de suivi]]
| [https://github.com/poitevie/Skitour/blob/main/rapport.md Rapport final] - [[Media:Presentation_finale_Skitour_2022-2023.pdf|Presentation finale FR]] - - [[Media:Skitour_2022-2023 Flyer.pdf|Flyer]] - [[Media:Presentation_mi_parcours_Skitour_2022-2023.pdf|Presentation de mi-parcours]] - [[Media:English_Poster_Skitour_2022-2023.pdf|Poster EN]] - [[Media:Pitch_Skitour_2022-2023.pdf|Pitch]]
| [https://github.com/poitevie/Skitour Dépôt Git]
| [[Media:Presentation_mi_parcours_Skitour_2022-2023.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[Assistant Vocal avec ChatGPT]]
| Julian ROYET (Chef de projet), Mirette GUIRGUIS, Keming ZHANG, Georges Harrisson SIMO YOKAM
| Didier Donsez
| [[Suivi Assistant Vocal avec ChatGPT 2022-2023|Fiche de suivi]]
| [[Rapport Studio XXX 2022-2023|Rapport final]] - [[Media:Presentation_finale_AssistantVocal_2022-2023.pdf|Presentation finale FR]] - - [[Media:Assistant_Vocal_2022-2023_Flyer.pdf|Flyer]] - [[Media:Presentation_mi_parcours_Assistant Vocal avec ChatGPT_2022-2023.pdf|Presentation de mi-parcours]] - [[Media:English_Poster_XXXX_2022-2023.pdf|Poster EN]] - [[Media:Pitch_AssistantVocal 2022-2023.pdf|Pitch]]
| [https://github.com/INFO5-Poly Dépôt Git]
| [[Media:Presentation_mi_parcours_Assistant Vocal avec ChatGPT_2022-2023.pdf|Presentation intermédiaire]]
|-

!scope="row"| 5
| [[ Adaptation à un protocole expérimentale d’une plateforme d’evaluation en ligne]]
| Étienne REYGNER (Chef de projet), Angelo ALIBERT
| Sybille Caffiau
| [[Suivi Eval en ligne 2022-2023|Fiche de suivi]]
| [[Rapport Studio XXX 2022-2023|Rapport final]] - [[Media:Presentation_finale_XXX_2022-2023.pdf|Presentation finale FR]] - - [[Media:XXX_2022-2023 Flyer.pdf|Flyer]] - [[Media:Soutenance_intermédiaire_5_REYGNER_ALIBERT.pdf|Presentation de mi-parcours]] - [[Media:English_Poster_Evaluation en ligne_2022-2023.pdf|Poster EN]] - [[Media:Pitch_XXX_2022-2023.pdf|Pitch]]
|
| [[Media:Presentation_mi_parcours_Studio Visite Virtuelle_2022-2023.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Mapillary RTK]]
| Fodor Gergely (Chef de projet), Kacha Tom, Conjard Samuel, Jardin Baptiste
| Nicolas Palix
| [[Suivi Mapillary RTK 2022-2023|Fiche de suivi]]
| [[https://github.com/PolyMapi/docs/blob/main/Rapport.md Rapport final]] - [[Media:Presentation_finale_G6_2022-2023.pdf|Presentation finale FR]] - - [[Media:G6_2022-2023 Flyer.pdf|Flyer]] - [[Media:Presentation_mi_parcours_G6_2022-2023.pdf|Presentation de mi-parcours]] - [[Media:English_Poster_G6_2022-2023.pdf|Poster EN]] - [[https://github.com/PolyMapi/docs/blob/main/pitch.md Pitch]]
| [https://github.com/orgs/PolyMapi/repositories Dépôt Git]
| [[Media:Presentation_mi_parcours_G6_2022-2023.pdf|Présentation intermédiaire]]
|-

!scope="row"| 7
| eCom suite
| Théo Capet (Chef de projet), Tom DA COSTA, Thomas Abecassis, Loris Mottino
| Jean-Rémi Bargin, Alexandre Lefebvre
| [[Suivi Studio XXXX 2022-2023|Fiche de suivi]]
| [[Rapport XXX 2022-2023|Rapport final]] - [[Media:Presentation_finale_XXX_2022-2023.pdf|Presentation finale FR]] - - [[Media:XXX_2022-2023 Flyer.pdf|Flyer]] - [[Media:Presentation_mi_parcours_XXX_2022-2023.pdf|Presentation de mi-parcours]] - [[Media:English_Poster_XXXX_2022-2023.pdf|Poster EN]] - [[Media:Pitch_XXX_2022-2023.pdf|Pitch]]
|
| [[Media:Presentation_mi_parcours_XXX_2022-2023.pdf|Présentation intermédiaire]]
|-

!scope="row"| 8
| [[Intégration LoRaWAN à la plateforme Domus]]
| Camille VIALLET (cheffe de projet), Emeric BRETON, Gaëtan LAVIROTTE, Cyprien PELISSE-VERDOUX
| Sybille Caffiau
| [[Suivi Studio Domus 2022-2023|Fiche de suivi]]
| [[https://github.com/Projet-INFO-S10/Domus-docs/blob/main/Livrables/Rapport%20final%20-%20Inte%CC%81gration%20de%20capteurs%20a%CC%80%20la%20pla%202856bf5e582e4c0287d0bc98cb4c1ad4.md Rapport final]] - [[Media:Presentation_finale_Domus_2022-2023.pdf|Presentation finale FR]] - - [[Media:Domus_2022-2023 Flyer.pdf|Flyer]] - [[Media:Presentation_mi_parcours_Domus_2022-2023.pdf|Presentation de mi-parcours]] - [[Media:English_Poster_Domus_2022-2023.pdf|Poster EN]] - [[Media:Pitch_Domus_2022-2023.pdf|Pitch]]
| [https://github.com/orgs/Projet-INFO-S10/repositories Dépot Git]
| [[Media:Presentation_mi_parcours_Domus_2022-2023.pdf|Présentation intermédiaire]]
|-

!scope="row"| 9
| POLYTECH SI
| Hadiby Chemsseddine (chef de projet), Hachem Mohsen, Brice Monthe
| Olivier Richard, Nicolas Palix
| [[Suivi Polytech SI 2022-2023|Fiche de suivi]]
| [[Rapport POLYTECH SI 2022-2023|Rapport final]] - [[Media:Presentation_finale_XXX_2022-2023.pdf|Presentation finale FR]] - - [[Media:XXX_2022-2023 Flyer.pdf|Flyer]] - [[Media:Presentation_mi_parcours_POLYTECH_SI_2022-2023.pdf|Presentation de mi-parcours]] - [[Media:Poster-Polytech-SI.pdf|Poster EN]] - [[Media:Pitch_XXX_2022-2023.pdf|Pitch]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/polytech1/pocs/ Dépot Git]
| [[Media:Presentation_mi_parcours_POLYTECH_SI_2022-2023.pdf|Présentation intermédiaire]]
|-

!scope="row"| 10
| [[Cinema Project Manager]] (CPM)
| Maël CHIOTTI (Chef de projet), Martin VERRIER, WAGNER Samy, CANIN Corentin
| [https://rvandco.fr Studio Rv & Co]
| [[Suivi Cinema Project Manager 2022-2023|Fiche de suivi]]
| [[https://github.com/StudioRvAndCo/CPM-documentation/blob/main/Rapport.md Rapport final]] - [[Media:Presentation_finale_Cinema Project Manager_2022-2023.pdf|Presentation finale FR]] - - [[Media:Cinema Project Manager_2022-2023 Flyer.pdf|Flyer]] - [https://air.imag.fr/images/0/0e/Soutenance_intermédiaire_CPM.pdf Presentation de mi-parcours] - [[Media:English_Poster_Cinema Project Manager_2022-2023.pdf|Poster EN]] - [[Media:Pitch_Cinema Project Manager_2022-2023.pdf|Pitch]]
| [https://github.com/StudioRvAndCo Dépôt Git]
| [https://air.imag.fr/images/0/0e/Soutenance_intermédiaire_CPM.pdf Presentation intermédiaire]
|-
|}

==== Sujets S10====

* 2 - [[Polytech-SI: une alternative à ADE]], Nicolas Palix (LIG/UGA), Olivier Richard (LIG/UGA)
* 3 - [[FitSize : Collections intelligentes]], Fidèle EYA’A, Jean-Marc INIKO (DigifitMode)
* 4 - [[ Adaptation à un protocole expérimentale d’une plateforme d’evaluation en ligne]], Christelle Martin-Lacroux (CERAG/UGA), Sybille Caffiau(LIG/UGA), Sophie Dupuy-Chessa (LIG/UGA)
* 5 - [[Intégration LoRaWAN à la plateforme Domus]], Sybille Caffiau(LIG/UGA)
* 6 - [[Suite du projet eCOM Suivi nutritionnel en EPHAD]] (à confirmer), Jean-Rémi BARGIN (Mutuelle Française Isère), Alexandre Lefebvre (MoonshotLabs)
* 7 - [[Carte neige et avalanches – Skitour.fr]], Jeroen Zijp (SkiTour)
* 8 - [[Mapillary RTK]] (à confirmer), Nicolas PALIX LIG/UGA
* 9 - [[Outil de création de visite virtuelle de bâtiments avec placement d'information temps réel]], Didier DONSEZ (LIG)
* 13 - [[Cinema Project Manager]] (CPM): [https://rvandco.fr/ Association Studio Rv & Co]
* 14 - Assistant Vocal avec ChatGPT, Julian Royet

==== Sujets non choisis ====
* 1 - [[Test d'infrastructures avec NixOS 2023]], Olivier Richard (LIG)
* 10 - [[Service de géolocalisation par TDOA LoRaWAN]], Didier DONSEZ (LIG/UGA), Olivier ALPHAND (LIG/GINP)
* <s>11 - [[Contributions open-source au projet JHipster]] (reporté à 2024) : Didier DONSEZ (LIG/UGA)</s>
* <s>12 - [[Contributions open-source au projet RIOT OS]] (reporté à 2024) : Didier DONSEZ (LIG/UGA)</s>

==== Annexes ====

Conseil: visitez les projets S10 des années précédentes.

===== Comment concevoir un poster qui accroche ? =====

* https://fr.wikihow.com/r%C3%A9aliser-une-affiche-scientifique

===== Comment concevoir un dépliant A4 3 volets (ie flyer) qui accroche ? =====

* https://www.jimprimeenfrance.fr/blog/comment-faire-un-depliant-sur-word/

===== Comment réaliser un pitch vidéo qui accroche ? =====

* https://www.dynamique-mag.com/article/pitch-video-solution-efficace-presenter-business.6199

=IESE=

==IESE5==

===Internet des Objets===

Enseignants : [[user:Donsez|Didier Donsez]], David Eon

====Objectif====

L’objectif du mini-projet de l'UE "Internet des Objets" est d’étudier du prototypage d’un objet connecté et du service associé.

La connectivité de l’objet peut être de type LoRaWAN, BLE ou Wifi (ou les 3 ensembles).

L’objet peut se baser sur un produit ou une carte d’évaluation à laquelle sont raccordés des capteurs (platine Grove par exemple). Les capteurs Grove et autres peuvent être emprunter au fablab via le service https://matos.univ-grenoble-alpes.fr/#/ .

L’objet LoRaWAN est identifié par son DevEUI et associé à une pièce ou à un lieu. Il peut être enregistré sur un réseau public en OTAA (TTN, Helium) ou sur un réseau privé en OTAA comme CampusIoT.

Les réseaux LoRaWAN utilisables en fonction de la couverture de votre site peuvent être :
* CampusIoT
* The Things Network
* Helium (10000 DC gratuit soit un message de 24 bytes par DC)

Pour l’affichage de données, vous pourrez utiliser des plateformes comme InfluxData, Cayenne, Thingsboard, Home assistant …

L’objectif du projet est de
* réaliser une analyse (rapide) du marché des produits commerciaux concurrents
* définir l’architecture globale du systèmes (ensemble d’objets, service en ligne (cloud)),
* définir la sécurité globale (clé de chiffrage),
* définir le respect de la vie privée du service (RGPD) : lister les risques d’atteinte au respect de la vie privée
* définir l’architecture matérielle de l’objet,
* estimer le coût de la BOM de votre produit (composants, PCB et enclosure) pour 5000 unités produites
** pour le boitier, vous pouvez rechercher des boitiers “standards” disponibles dans les catalogues fournisseurs
** pour le PCB, vous pouvez fournir une estimation du prix de fabrication du PCB et du masque chez des fournisseurs comme https://jlcpcb.com/ , https://www.wedirekt.fr/fr/ …
* estimer le coût de certification ETSI du produit, le coût de certification LoRa Alliance du produit ...
* proposer une implémentation du logiciel embarqué de l’objet défini.
* définir/documenter le format des messages uplink et downlink échangés (dans le cas des objets LoRaWAN, privilégiez le format LPP)
* définir le logiciel embarqué de l’objet.
* donner les métriques logiciel du logiciel embarqué (nombre de lignes de code, taille du binaire du firmware ie le fichier .bin)
* instrumenter le logiciel embarqué pour mesurer les différents temps d’exécution des principales phases d’exécution (par exemple: durée d’une prise de photo, écriture sur carte SD, inférences avec un réseau de neurones …)
** prévoir de montrer la trace console de l’objet pendant la démonstration.
* estimer la durée de vie de la batterie de l’objet (pour LoRaWAN en fonction du datarate comme avec l’outil https://www.elsys.se/en/battery-life-calculator/
* réaliser une analyse (brève) du cycle de vie du produit “durable” et “sobre” (ACV)
* rechercher et analyser (avantages/inconvénients sous la forme d’une grille) des produits concurrents
* montrer les intégrations effectuées (cayenne, influxdb, home assistant, jupyter notebook …)
* compter le nombre de lignes de code développé (coté objet, coté application) avec un outil comme cloc. Précisez les langages et les outils utilisés (git, arduino-cli …)

Le firmware (si RIOT ou FreeRTOS) doit activer le watchdog timer afin de redémarrer en cas de crash logiciel.

Vous pourrez « fabriquer » un boîtier de la version prototype de l’objet en utilisant une imprimante 3D ou la découpeuse laser disponibles au fablab.

====Projets====

* Détection d’ouverture de porte/fenêtre (avec Home Assistant)
* Suivi de troupeaux de bovins : détection d’anomalie (attaque des prédateurs …)
* Mesure d’occupation du salle et de niveau de confort sonore (de bruit)
* Comptage de vehicules avec YOLO
* Comptage de personnes avec YOLO
* Nichoir connecté (remarque: semblable aux ruches connectés de Polytech). Contribution à RIOT OS
* Artificial Noise et LoRaWAN
* Affichage d’un QRCode régénéré périodiquement sur écran e-Paper (gestion de files d’attente virtuelle, ronde de surveillance, course d’orientation, réservation d’une salle, collecte de tickets de réduction …). Contribution à RIOT OS
* Remontée d’info véhicule via LoRaWAN. (Il faut une voiture avec une prise ODB-II). Contribution à RIOT OS
* Détection (comptage) de personnes
* Prise connectée LoRaWAN : Mesure de consommation de courant. Contribution à RIOT OS
* Scanner QRCode pour ouverture de porte

File:English Poster Cinema Project Manager 2022-2023.pdf

2023-03-15T22:24:47Z

Martin.Verrier:

File:Cinema Project Manager 2022-2023 Flyer.pdf

2023-03-15T22:21:37Z

Martin.Verrier:

File:Presentation finale Cinema Project Manager 2022-2023.pdf

2023-03-15T22:21:03Z

Martin.Verrier:

Suivi Cinema Project Manager 2022-2023

2023-03-15T16:24:08Z

Martin.Verrier:

= L'équipe =

== Les élèves ==

* Maël CHIOTTI
* Samy WAGNER
* Corentin CANIN
* Martin VERRIER

== Les porteurs du projet ==

* Maël CHIOTTI

= Suivi de projet =

== Semaine 1 - du 16/01 au 21/01 ==

* Choix des technologies
* Etablissement cahier des charges

== Semaine 2 - du 23/01 au 27/01 ==

* Confection maquette figma Mobile

== Semaine 3 - du 30/01 au 03/02 ==

* Confection maquette figma Web
* Formation équipe à Flutter

== Semaine 4 - du 06/01 au 10/02 ==

* Mise en place de la BDD mongoDB
* Début du développement frontend

== Semaine 5 - du 20/01 au 24/02 ==

* Développement frontend
* Début du développement backend

== Semaine 6 - du 27/02 au 03/03 ==

* Développement frontend
* Développement backend

== Semaine 7 - du 06/03 au 10/03 ==

* Préparation du Poster
* Développement frontend
* Développement backend

== Semaine 8 - du 13/03 au 17/03 ==

* Finalisation code frontend
* Finalisation code backend
* Confection du rapport
* Préparation de la soutenance

Suivi Cinema Project Manager 2022-2023

2023-03-15T16:19:55Z

Martin.Verrier: Created page with "= L'équipe = == Les élèves == * Maël CHIOTTI * Samy WAGNER * Corentin CANIN * Martin VERRIER == Les porteurs du projet == * = Suivi de projet = == Semaine 1 - du 16..."

= L'équipe =

== Les élèves ==

* Maël CHIOTTI
* Samy WAGNER
* Corentin CANIN
* Martin VERRIER

== Les porteurs du projet ==

*

= Suivi de projet =

== Semaine 1 - du 16/01 au 21/01 ==

* Choix des technologies
* Etablissement cahier des charges

== Semaine 2 - du 23/01 au 27/01 ==

* Confection maquette figma Mobile

== Semaine 3 - du 30/01 au 03/02 ==

* Confection maquette figma Web
* Formation équipe à Flutter

== Semaine 4 - du 06/01 au 10/02 ==

*

== Semaine 5 - du 20/01 au 24/02 ==

*

== Semaine 6 - du 27/02 au 03/03 ==
*

== Semaine 7 - du 06/03 au 10/03 ==
*

Cinema Project Manager

2023-01-15T18:01:31Z

Martin.Verrier:

Encadrant enseignant: TBC

Product owner: Bastien Moirez Charron

Parrain: [https://rvandco.fr Studio Rv & Co]

Etudiants (4 max):
* Maël Chiotti
* Corentin Canin
* Samy Wagner
* Martin Verrier

[[Cinema Project Manager]] (CPM) est proposé par l'association [https://rvandco.fr/ Studio Rv & Co].

L'association est spécialisée dans la production audiovisuelle. Elle a pour projet de développer une application de gestion de projet cinématographique.

L'application Cinema Project Manager (CPM) permettrait de documenter et organiser différents projets, de la phase de pré-production (planning de tournage, scénario, découpage technique) en passant par la production (association d'acteurs à un personnage, liste des costumes et accessoires) jusqu'à la post-production (avancée du montage et des effets spéciaux).

Grâce à cette application, l'association pourrait augmenter en efficacité, d'une part en regroupant tous les documents relatifs à un projet (autorisations de tournage, plannings, scénarios etc.) en un seul endroit mais aussi en apportant une vraie facilité d'organisation pour les plannings, en intégrant les disponibilités de chaque acteur du projet.

Langages de programmation:

Canevas frontend: [https://www.electronjs.org/ Electron JS] ? Gestion de l'internationalisation ? Mode offline (resynchronisation de modification) ?

Canevas backend: Micro-services ?

Persistance: Base de données (avec versionnement) ? Wiki ? Git (commit ? tags ? branch ?) ?

Méthodes: Scrum ? Kanban ?

VT2022

2022-11-28T16:06:51Z

Martin.Verrier: /* Séance 4 : 28/11 */

[[VT2021|<< Etudes 2021]] [[VT|Sommaire]] [[VT2023|Etudes 2023 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en INFO5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.

Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Chaque séance comporte 3 à 4 présentations suivi chacune d'une démonstration. Chaque présentation dure entre 20 et 25 minutes en fonction des séances. Pour plus de sécurité, la démonstration peut être pré-enregistrée.

Votre présentation sera réalisée de préférence avec [[reveal.js]] ou avec [[remarkjs]].

Votre présentation sera notée et commentée par tous vos camarades via un sondage (smartphone). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu en vaut-il la chandelle ?

[[File:presentation-VT-INFO5-2122.pdf|transparents d'introduction à l'UE]]

=Planning=

== Séance 1 : 07/11 (réporté)==

== Séance 2 : 14/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

Présentation et organisation.

== Séance 3 : 21/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[AdTech et capitalisme de surveillance]]: Julien Guigard, Angelo Alibert [[Media:VT2022_Adtech_presentation.pdf|présentation]], [[Media:AdTech et capitalisme de surveillance Rapport écrit.pdf|fiche]], [[VT2022_Adtech_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Oeuvres d'art générées par une IA]] : DALL-E 2, Midjourney et Stable Diffusion : Kacha, Jardin [[Media:VT2022_AIArt_presentation.pdf|présentation]], [[Media:VT2022 AIArt synthese.pdf|fiche]], [[VT2022_AIArt_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Ansible]]: Da Costa [[Media:VT2022_Ansible_presentation.pdf|présentation]], [[VT2022_Ansible_fiche|fiche]], [[VT2022_Ansible_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 4 : 28/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[Web Assembly et Smart Contracts]]: Verrier, Mottino [[Media:Web_assembly_&_smart_contracts.pdf|présentation]], [[VT2022_WebAssemblyEtSmartContracts_fiche|fiche]], [[VT2022_WebAssemblyEtSmartContracts_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[GPT Neo|GPT la suite]] : Monthe Djeumou, Simo Yokam [[Media:VT2022_GPT_presentation.pdf|présentation]], [[VT2022_GPT_fiche|fiche]], [[VT2022_GPT_demo|demo]], [https://montube.com/GPTAZERTYUIO screencast]
* [[Implants rétiniens]]: Bernerd, NGuyen Justin [[Media:VT_Implants_Rétiniens.pdf|présentation]], [[Media:Fiche_de_synthèse.pdf|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 5 : 05/12 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* WebRTC: Hadiby, Mohsen [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Voice-First Development : Designing, Developing, and Deploying Conversational Interfaces: Conjard, Fodor [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Helium: Lavirotte, Pelisse [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Internet of Audio Things]]: Teyssier, Drouin [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 6 : 12/12 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* NVidia [[Deep learning super sampling (DLSS)]]: Canin, Wagner [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* OpenPose (ou autre): Poitevin, Reygner [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* AzureRTOS: Bach, Chiotti [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Post-quantum cryptography]] : Zhang, Guiguis [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 7 : 09/01 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* Vote électronique : Abecassis [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* NFT : plateformes, technologies, vices et vertus: Faghloumi [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Géo-localisation Wifi : Fournier [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Generation of ASMR (Autonomous sensory meridian response)]]: Chappaz, De Oliveira [[Media:VT2022_ASMR_presentation.pdf|présentation]], [[VT2022_ASMR_fiche|fiche]], [[VT2022_ASMR_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 8 : 16/01 (très probablement en distanciel) ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[IPFS (InterPlanetary File System)]]: Capet, Royer [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Low Code Development]] : Breton, Nguyen Clément [[Media:VT2022_LowCode_presentation.pdf|présentation]], [[Media:VT2022_LowCode_fiche.pdf|fiche]], [[Media:VT2022_LowCode_demo.pdf|demo]], [https://montube.com/AZERTYUIO screencast]

=Sujets=
# [[Oeuvres d'art générées par une IA]] : DALL-E 2, Midjourney et Stable Diffusion
# [[GPT Neo]]
# [[Predictive networks]]
# [[Objectives and Key Results]]
# [[Implants rétiniens]]
# [[Post-quantum cryptography]]
# [[Internet of Audio Things]]
# [[uFS]] : a user-level filesystem semi-microkernel
# [[Generation of ASMR (Autonomous sensory meridian response)]]
# [[Wasm|WebAssembly]]
# [[Web Assembly et Smart Contracts]]
# [[Application Performance Monitoring]] : démonstration de [[Apache Skywalking]]
# [[Low Code Development]]
# [[Multi-Region Database Deployments: Patterns and Anti-Patterns]] : démonstration avec [[Cockroack]]
# [[Proof of Coverage Blockchain]] : démonstration d'[[Helium]]
# [[IPFS (InterPlanetary File System)]]
# [[Géolocalisation Wifi : principles et services de géolocalisation Wifi et cellulaire]]
# [[Caches distribués]]: démonstration avec [[Redis]]
# [[NEMU]] : open source hypervisor specifically built and designed to run modern cloud workloads on modern 64-bit Intel and ARM CPUs.
# [[Fission]] : open-source serverless function framework for [[Kubernetes]] with a focus on developer productivity and high performance.
# [[AdTech et Surveillance capitalism]]
# [[Conflict-free replicated data type]] (CRDT)
# [[ Voice-First Development]] : Designing, Developing, and Deploying Conversational Interfaces
# [[AzureRTOS]] : système d'exploitation pour l'Internet des Objets. démonstration sur [https://www.st.com/en/evaluation-tools/b-l475e-iot01a.html B-L475] à récupérer au fablab.
# Algorithmes et systèmes de vote électronique : vices et vertus.
# [[Pantavisor Linux]]: A Framework for Building Containerized IoT Systems
# [[WebRTC]] : Web Real-Time Communication
# [[uFS]] : a user-level filesystem semi-microkernel
# [[Bundle Protocol]]
# [[NFT]] : plateformes, technologies, vices et vertues.
# [[MLOps]] : DevOps for Machine Learning projects

VT2022

2022-11-28T16:06:02Z

Martin.Verrier: /* Séance 4 : 28/11 */

[[VT2021|<< Etudes 2021]] [[VT|Sommaire]] [[VT2023|Etudes 2023 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en INFO5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.

Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Chaque séance comporte 3 à 4 présentations suivi chacune d'une démonstration. Chaque présentation dure entre 20 et 25 minutes en fonction des séances. Pour plus de sécurité, la démonstration peut être pré-enregistrée.

Votre présentation sera réalisée de préférence avec [[reveal.js]] ou avec [[remarkjs]].

Votre présentation sera notée et commentée par tous vos camarades via un sondage (smartphone). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu en vaut-il la chandelle ?

[[File:presentation-VT-INFO5-2122.pdf|transparents d'introduction à l'UE]]

=Planning=

== Séance 1 : 07/11 (réporté)==

== Séance 2 : 14/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

Présentation et organisation.

== Séance 3 : 21/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[AdTech et capitalisme de surveillance]]: Julien Guigard, Angelo Alibert [[Media:VT2022_Adtech_presentation.pdf|présentation]], [[Media:AdTech et capitalisme de surveillance Rapport écrit.pdf|fiche]], [[VT2022_Adtech_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Oeuvres d'art générées par une IA]] : DALL-E 2, Midjourney et Stable Diffusion : Kacha, Jardin [[Media:VT2022_AIArt_presentation.pdf|présentation]], [[Media:VT2022 AIArt synthese.pdf|fiche]], [[VT2022_AIArt_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Ansible]]: Da Costa [[Media:VT2022_Ansible_presentation.pdf|présentation]], [[VT2022_Ansible_fiche|fiche]], [[VT2022_Ansible_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 4 : 28/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[Web Assembly et Smart Contracts]]: Verrier, Mottino [[File:Web_assembly_&_smart_contracts.pdf|présentation]], [[VT2022_WebAssemblyEtSmartContracts_fiche|fiche]], [[VT2022_WebAssemblyEtSmartContracts_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[GPT Neo|GPT la suite]] : Monthe Djeumou, Simo Yokam [[Media:VT2022_GPT_presentation.pdf|présentation]], [[VT2022_GPT_fiche|fiche]], [[VT2022_GPT_demo|demo]], [https://montube.com/GPTAZERTYUIO screencast]
* [[Implants rétiniens]]: Bernerd, NGuyen Justin [[Media:VT_Implants_Rétiniens.pdf|présentation]], [[Media:Fiche_de_synthèse.pdf|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 5 : 05/12 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* WebRTC: Hadiby, Mohsen [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Voice-First Development : Designing, Developing, and Deploying Conversational Interfaces: Conjard, Fodor [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Helium: Lavirotte, Pelisse [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Internet of Audio Things]]: Teyssier, Drouin [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 6 : 12/12 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* NVidia [[Deep learning super sampling (DLSS)]]: Canin, Wagner [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* OpenPose (ou autre): Poitevin, Reygner [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* AzureRTOS: Bach, Chiotti [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Post-quantum cryptography]] : Zhang, Guiguis [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 7 : 09/01 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* Vote électronique : Abecassis [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* NFT : plateformes, technologies, vices et vertus: Faghloumi [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Géo-localisation Wifi : Fournier [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Generation of ASMR (Autonomous sensory meridian response)]]: Chappaz, De Oliveira [[Media:VT2022_ASMR_presentation.pdf|présentation]], [[VT2022_ASMR_fiche|fiche]], [[VT2022_ASMR_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 8 : 16/01 (très probablement en distanciel) ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[IPFS (InterPlanetary File System)]]: Capet, Royer [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Low Code Development]] : Breton, Nguyen Clément [[Media:VT2022_LowCode_presentation.pdf|présentation]], [[Media:VT2022_LowCode_fiche.pdf|fiche]], [[Media:VT2022_LowCode_demo.pdf|demo]], [https://montube.com/AZERTYUIO screencast]

=Sujets=
# [[Oeuvres d'art générées par une IA]] : DALL-E 2, Midjourney et Stable Diffusion
# [[GPT Neo]]
# [[Predictive networks]]
# [[Objectives and Key Results]]
# [[Implants rétiniens]]
# [[Post-quantum cryptography]]
# [[Internet of Audio Things]]
# [[uFS]] : a user-level filesystem semi-microkernel
# [[Generation of ASMR (Autonomous sensory meridian response)]]
# [[Wasm|WebAssembly]]
# [[Web Assembly et Smart Contracts]]
# [[Application Performance Monitoring]] : démonstration de [[Apache Skywalking]]
# [[Low Code Development]]
# [[Multi-Region Database Deployments: Patterns and Anti-Patterns]] : démonstration avec [[Cockroack]]
# [[Proof of Coverage Blockchain]] : démonstration d'[[Helium]]
# [[IPFS (InterPlanetary File System)]]
# [[Géolocalisation Wifi : principles et services de géolocalisation Wifi et cellulaire]]
# [[Caches distribués]]: démonstration avec [[Redis]]
# [[NEMU]] : open source hypervisor specifically built and designed to run modern cloud workloads on modern 64-bit Intel and ARM CPUs.
# [[Fission]] : open-source serverless function framework for [[Kubernetes]] with a focus on developer productivity and high performance.
# [[AdTech et Surveillance capitalism]]
# [[Conflict-free replicated data type]] (CRDT)
# [[ Voice-First Development]] : Designing, Developing, and Deploying Conversational Interfaces
# [[AzureRTOS]] : système d'exploitation pour l'Internet des Objets. démonstration sur [https://www.st.com/en/evaluation-tools/b-l475e-iot01a.html B-L475] à récupérer au fablab.
# Algorithmes et systèmes de vote électronique : vices et vertus.
# [[Pantavisor Linux]]: A Framework for Building Containerized IoT Systems
# [[WebRTC]] : Web Real-Time Communication
# [[uFS]] : a user-level filesystem semi-microkernel
# [[Bundle Protocol]]
# [[NFT]] : plateformes, technologies, vices et vertues.
# [[MLOps]] : DevOps for Machine Learning projects

File:Web assembly & smart contracts.pdf

2022-11-28T16:04:42Z

Martin.Verrier:

VT2022 WebAssemblyEtSmartContracts fiche

2022-11-28T15:55:38Z

Martin.Verrier: /* Références */

=Résumé=

WebAssembly, est un format d'instruction binaire basé sur une machine à pile. Cette technologie permet entre autres de compiler du code de n’importe quel langage en fichier .wasm. Ces fichiers binaires sont alors très peu coûteux en stockage, et peuvent être exécutés sur n’importe quelle architecture machine, mais également intégrés à du code JavaScript par exemple. Cela permet aux technologies du web de pouvoir exécuter du code déjà compilé, provenant d’autres langages, pouvant être plus performants pour certaines tâches.

Cette technologie peut alors parfaitement s’intégrer à la blockchain, afin de coder des smart contracts plus performants. En effet, les programmes des smart contracts ont besoin de répondre à deux problématiques majeures, qui sont la taille du fichier, et la possibilité d’exécuter ces programmes sur n’importe quelle architecture machine.

WebAssembly répond à ces critères, et permet d’écrire des smart contracts dans des langages performants tel que C, C++, C# ou encore Rust. Cela semble alors être une technologie révolutionnaire pour le milieu des smart contracts.

=Abstract=

WebAssembly is a binary instruction format based on a stack machine. This technology allows, among other things, to compile code of any language into .wasm files. These binary files are then very cheap in storage, and can be executed on any machine architecture, but also integrates well with JavaScript code for example. This allows web technologies to run already compiled code from other languages, which can be more efficient for certain tasks.

This technology can then be perfectly integrated with the blockchain, in order to propose more efficient smart contracts. Indeed, smart contract programs need to answer two major issues, which are the file size, and the possibility to run these programs on any machine architecture.
WebAssembly meets these criteria, and allows to write smart contracts in powerful languages such as C, C++, C# or even Rust. It seems then to be a revolutionary technology for the smart contract community.

=I. WEB ASSEMBLY=

==1. ETAT DES TECHNOLOGIES DU WEB AVANT WEBASSEMBLY==

On observe deux phases importantes dans l’évolution des technologies du web, et plus particulièrement de JavaScript.
Au tout début, le langage JavaScript était exécuté via un interpréteur. Cet interpréteur permet de se passer du temps de compilation d’un fichier (par opposition au compilateur) et donc de gagner en performance. En effet, pour rappel, à l’inverse d’un compilateur qui va traduire l’ensemble du code en langage machine avant l’exécution, l’interpréteur traduit uniquement la ligne qu’il est en train d’exécuter, et exécute ainsi le programme ligne par ligne.

Cependant, cette méthode a ses limites et a amené les technologies du web à évoluer, vers ce que nous allons appeler la phase 2, avec l’utilisation des compilateurs Just-In-Time (JIT).

En effet, l’utilisation de l’interpréteur pose plusieurs soucis de performances. Imaginons que vous rechargiez une page web, le code devra alors être de nouveau exécuté entièrement par l’interpréteur. Alors que si nous avions compilé le code via un compilateur lors de la première itération, nous n’aurions qu’à exécuter le code précédemment compilé directement. Ce problème de réinterprétation du code peut également survenir dans les boucles, où nous pourrions simplement compiler la ligne de code qui sera exécutée plusieurs fois, plutôt que de l’interpréter à chaque tour de boucle.

Oui mais, changer pour une utilisation du compilateur à la place de l’interpréteur ferait perdre en performance dans le cas où nous utilisons des pages statiques. C’est pourquoi, le compilateur JIT a été inventé pour résoudre ce problème.

Comment fonctionne un compilateur JIT ?

Un compilateur Just-In-Time fonctionne de la même manière qu’un interpréteur, à la différence qu’il va compiler certaines portions de code au cours de l’exécution. En effet, lors de l’exécution d’un programme il va identifier si une portion de code « chauffe » beaucoup ou non, et décider de compiler ces portions de code en fonction de leur état. On dit alors que du code chauffe s’il est interprété plusieurs fois (dans une boucle par exemple). Ainsi les portions de code qui chauffent seront compilées et stockées, afin de pouvoir exécuter directement le code compilé lors de sa prochaine exécution. De plus, afin d’optimiser la compilation, le JIT fais des hypothèses sur le code compilé, comme par exemple le type des variables.

Comme vous le savez peut-être, JavaScript est un langage non typé, et peut donc contenir des structures de données avec des types non homogènes. Ainsi, le JIT va faire une hypothèse sur le type des données traités lors de la compilation. Ainsi, lors de la prochaine exécution il vérifiera si son hypothèse est juste avant d’exécuter le code compilé. Si jamais son hypothèse est fausse, il va alors faire une « désoptimisation » en supprimant le code compilé. L’exécution sera alors assurée par l’interpréteur, et peut être plus tard recompilé à nouveau suivant de nouvelles hypothèses.

==2. WEB ASSEMBLY==

Avec l’arrivée du compilateur JIT, les performances du Web ont explosé, avant de de nouveau stagner (état des technologies actuelles). C’est pourquoi, les grandes entreprises telles que Google, Mozilla, Apple, Microsoft et W3C ont commencé à travailler sur une nouvelle technologie : WebAssembly, pour répondre aux nouvelles problématiques de performances.

En effet, le problème que pose aujourd’hui le JIT est la grande perte de performance lors de l’étape d’optimisation du code compilé et la désoptimisation, étapes qui peuvent se répéter indéfiniment. Ainsi, l’objectif de WebAssembly est de supprimer cette étape.
Pour ce faire, WebAssembly permet de générer des fichiers binaires .wasm qui peuvent être obtenus en compilant n’importe quel langage de programmation en .wasm. WebAssembly est une machine à pile, c’est-à-dire que les fichiers binaires générés ne stockent pas les registres dont sont issus les données pour effectuer les calculs. Cela permet entre autres de produire des fichiers très légers, qui sont alors rapidement transférables et peu gourmands en stockage. De plus, ces fichiers peuvent être ensuite exécutés sur n’importe quelle architecture de machine. Grâce à sa compatibilité avec toutes sortes de langages, les modules .wasm peuvent, par exemple, alors être intégrés à du code JavaScript.

En quoi WebAssembly rend alors JavaScript et les autres technologies du web plus performantes ?

Grâce à Web Assembly il est maintenant possible d’exécuter du code compilé, issu d’autres langages tel que C, C++, C# ou encore Rust, qui sont des langages plus optimisés pour effectuer certaines tâches. Ainsi, il nous est possible d’écrire un code en JavaScript qui utilise du code C compilé en .wasm, qui viendra remplacer les portions de code « chaudes » qui étaient précédemment compilées, optimisées, désoptimisées, et recompilées par le JIT.

De plus, grâce à leurs petites tailles, les fichiers .wasm sont très peut coûteux à être importés et donc ne créent pas de latence supplémentaire.

Pour finir, on peut trouver une autre application à Web Assembly en dehors de la recherche de performances. En effet, puisqu’il est maintenant possible d’exécuter du code C, C++, C#, Rust… pour le web, il n’est plus nécessaire de réécrire du code en JavaScript si une alternative dans un autre langage existe déjà, et a déjà prouvé son efficacité. Permettant ainsi de faciliter le travail des développeurs et de mettre en place un « pont » entre les langages, au service du web.

=II. SMART CONTRACTS=

==1. BLOCKCHAIN & SMART CONTRACTS==

« Une blockchain est une base de données décentralisée publique. » Expliquons rapidement cette phrase.
Tout d’abord, afin de comprendre pourquoi nous parlons de décentralisation, il faut comprendre ce qu’est un « tier de confiance ». Un « tier de confiance » est une personne (morale ou non) qui est chargée d’assurer un service entre deux personnes. Par exemple, la banque est le tier de confiance utilisé pour une transaction monétaire, mais encore, quand vous souhaitez accéder à vos données stockées dans le cloud, vous faites appel à un tier de confiance (par exemple Amazon) qui vous assure de stocker vos informations et de vous permettre d’y accéder. Le système basé sur les tiers de confiances est ce qu’on appelle un système « centralisé ». En effet, une banque, ou une ferme de serveurs, se charge de centraliser les transactions ou le stockage des données.

Ainsi, l’objectif de la décentralisation est de se passer de ces tiers de confiance. Pour ce faire, la blockchain est manipulée par des centaines de milliers de personnes, qui possèdent tous un même registre. Ensuite, afin de modifier ce registre, pour inscrire une nouvelle information, l’entièreté des personnes qui contribuent à ce registre doivent valider la modification. Le registre est alors décentralisé, puisqu’il n’est plus géré par une unique entité.

De plus, quand on parle de blockchain, on parle de base de données publique. En effet, une blockchain n’est ni plus ni moins qu’un registre informatique où l’on peut stocker des informations de manière sécurisée. Ainsi, par sa propriété à être décentralisée, ce registre est public, n’importe quelle personne peut venir consulter les informations qu’il contient, le stocker et contribuer aux validations des prochaines modifications.

Un smart contract ou « contrat intelligent », pour sa part, est un contrat passé entre deux entités, inscris de manière immuable dans la blockchain. Il permet de jouer le rôle des tiers de confiance dans un système centralisé. En effet, un smart contract n’est ni plus ni moins qu’un code informatique se trouvant dans une blockchain, qui fixe le cadre d’un contrat. Il définit les actions à réaliser, lorsque les conditions voulues par les parties l’ayant signé sont respectées. Ils sont aujourd’hui écrits dans des langages de programmations tel que Solidity, qui sont basés sur JavaScript.

==2. UTILISATION DE WEBASSEMBLY POUR ECRIRE DES SMART CONTRACTS==

Tout d’abord, les langages tel que Solidity sont des langages pensés pour être exécutés sur la blockchain. En effet, la blockchain impose plusieurs contraintes au langage, qui ont forcé les développeurs à concevoir des langages spécifiques pour y répondre. Parmi ces contraintes, les deux plus importantes sont :

- La nécessité d’avoir un programme peu couteux en stockage.
o En effet plus les fichiers sont volumineux, plus ils sont coûteux à inscrire dans la blockchain.
- La nécessité d’avoir des programmes exécutables sur n’importe quelle machine.
o En effet, comme expliqué précédemment, la blockchain peut être stockée par n’importe quel individu. Ainsi, les programmes des smart contracts doivent pouvoir s’exécuter sur la machine de ces individus, quelle que soit leur architecture.

Cependant, les langages comme Solidity répondent à ces exigences, mais font face à d’autres problèmes. En effet, ces langages sont peu performants, et surtout spécifiques à l’utilisation sur une bolckchain. Cette spécificité implique le besoin d’une main d’œuvre qualifiée dans un domaine « de niche ».

C’est à ce moment que Web Assembly trouve toute son application pour les smart conrtacts. En effet, comme nous l’avons vu précédemment, les fichiers .wasm sont des fichiers peu coûteux en stockage, et exécutables sur toutes les architectures machines. WebAssembly répond ainsi aux exigences de la blockchain, mais plus encore.

WebAssembly permet d’obtenir un fichier .wasm à partir d’autres langages de haut niveau. Ainsi, cela permet d’ouvrir la programmation de smart contracts à d’autres langages de programmation. Permettant alors d’avoir accès à une main œuvre qualifiée beaucoup plus grande, mais également à des langages plus performants et optimisés pour effectuer certaines tâches.

WebAssembly semble donc être le futur des smart contracts et permettra sans aucun doute, comme elle le fait avec les technologies du web, d’ouvrir de nouvelles possibilités aux smart contracts.

=Références=

Explication WebAssembly :
https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/

WebAssembly Smart Contracts :
https://blog.scottlogic.com/2019/11/26/webassembly-on-the-blockchain.html

VT2022 WebAssemblyEtSmartContracts fiche

2022-11-28T15:22:06Z

Martin.Verrier: Created page with "RESUME WebAssembly, est un format d'instruction binaire basé sur une machine à pile. Cette technologie permet entre autres de compiler du code de n’importe quel langage e..."

RESUME

WebAssembly, est un format d'instruction binaire basé sur une machine à pile. Cette technologie permet entre autres de compiler du code de n’importe quel langage en fichier .wasm. Ces fichiers binaires sont alors très peu coûteux en stockage, et peuvent être exécutés sur n’importe quelle architecture machine, mais également intégrés à du code JavaScript par exemple. Cela permet aux technologies du web de pouvoir exécuter du code déjà compilé, provenant d’autres langages, pouvant être plus performants pour certaines tâches.
Cette technologie peut alors parfaitement s’intégrer à la blockchain, afin de coder des smart contracts plus performants. En effet, les programmes des smart contracts ont besoin de répondre à deux problématiques majeures, qui sont la taille du fichier, et la possibilité d’exécuter ces programmes sur n’importe quelle architecture machine.
WebAssembly répond à ces critères, et permet d’écrire des smart contracts dans des langages performants tel que C, C++, C# ou encore Rust. Cela semble alors être une technologie révolutionnaire pour le milieu des smart contracts.

ABSTRACT

WebAssembly is a binary instruction format based on a stack machine. This technology allows, among other things, to compile code of any language into .wasm files. These binary files are then very cheap in storage, and can be executed on any machine architecture, but also integrates well with JavaScript code for example. This allows web technologies to run already compiled code from other languages, which can be more efficient for certain tasks.
This technology can then be perfectly integrated with the blockchain, in order to propose more efficient smart contracts. Indeed, smart contract programs need to answer two major issues, which are the file size, and the possibility to run these programs on any machine architecture.
WebAssembly meets these criteria, and allows to write smart contracts in powerful languages such as C, C++, C# or even Rust. It seems then to be a revolutionary technology for the smart contract community.

I. WEB ASSEMBLY

1. ETAT DES TECHNOLOGIES DU WEB AVANT WEBASSEMBLY

On observe deux phases importantes dans l’évolution des technologies du web, et plus particulièrement de JavaScript.
Au tout début, le langage JavaScript était exécuté via un interpréteur. Cet interpréteur permet de se passer du temps de compilation d’un fichier (par opposition au compilateur) et donc de gagner en performance. En effet, pour rappel, à l’inverse d’un compilateur qui va traduire l’ensemble du code en langage machine avant l’exécution, l’interpréteur traduit uniquement la ligne qu’il est en train d’exécuter, et exécute ainsi le programme ligne par ligne.
Cependant, cette méthode a ses limites et a amené les technologies du web à évoluer, vers ce que nous allons appeler la phase 2, avec l’utilisation des compilateurs Just-In-Time (JIT).
En effet, l’utilisation de l’interpréteur pose plusieurs soucis de performances. Imaginons que vous rechargiez une page web, le code devra alors être de nouveau exécuté entièrement par l’interpréteur. Alors que si nous avions compilé le code via un compilateur lors de la première itération, nous n’aurions qu’à exécuter le code précédemment compilé directement. Ce problème de réinterprétation du code peut également survenir dans les boucles, où nous pourrions simplement compiler la ligne de code qui sera exécutée plusieurs fois, plutôt que de l’interpréter à chaque tour de boucle.
Oui mais, changer pour une utilisation du compilateur à la place de l’interpréteur ferait perdre en performance dans le cas où nous utilisons des pages statiques. C’est pourquoi, le compilateur JIT a été inventé pour résoudre ce problème.
Comment fonctionne un compilateur JIT ?
Un compilateur Just-In-Time fonctionne de la même manière qu’un interpréteur, à la différence qu’il va compiler certaines portions de code au cours de l’exécution. En effet, lors de l’exécution d’un programme il va identifier si une portion de code « chauffe » beaucoup ou non, et décider de compiler ces portions de code en fonction de leur état. On dit alors que du code chauffe s’il est interprété plusieurs fois (dans une boucle par exemple). Ainsi les portions de code qui chauffent seront compilées et stockées, afin de pouvoir exécuter directement le code compilé lors de sa prochaine exécution. De plus, afin d’optimiser la compilation, le JIT fais des hypothèses sur le code compilé, comme par exemple le type des variables.
Comme vous le savez peut-être, JavaScript est un langage non typé, et peut donc contenir des structures de données avec des types non homogènes. Ainsi, le JIT va faire une hypothèse sur le type des données traités lors de la compilation. Ainsi, lors de la prochaine exécution il vérifiera si son hypothèse est juste avant d’exécuter le code compilé. Si jamais son hypothèse est fausse, il va alors faire une « désoptimisation » en supprimant le code compilé. L’exécution sera alors assurée par l’interpréteur, et peut être plus tard recompilé à nouveau suivant de nouvelles hypothèses.

2. WEB ASSEMBLY

Avec l’arrivée du compilateur JIT, les performances du Web ont explosé, avant de de nouveau stagner (état des technologies actuelles). C’est pourquoi, les grandes entreprises telles que Google, Mozilla, Apple, Microsoft et W3C ont commencé à travailler sur une nouvelle technologie : WebAssembly, pour répondre aux nouvelles problématiques de performances.
En effet, le problème que pose aujourd’hui le JIT est la grande perte de performance lors de l’étape d’optimisation du code compilé et la désoptimisation, étapes qui peuvent se répéter indéfiniment. Ainsi, l’objectif de WebAssembly est de supprimer cette étape.
Pour ce faire, WebAssembly permet de générer des fichiers binaires .wasm qui peuvent être obtenus en compilant n’importe quel langage de programmation en .wasm. WebAssembly est une machine à pile, c’est-à-dire que les fichiers binaires générés ne stockent pas les registres dont sont issus les données pour effectuer les calculs. Cela permet entre autres de produire des fichiers très légers, qui sont alors rapidement transférables et peu gourmands en stockage. De plus, ces fichiers peuvent être ensuite exécutés sur n’importe quelle architecture de machine. Grâce à sa compatibilité avec toutes sortes de langages, les modules .wasm peuvent, par exemple, alors être intégrés à du code JavaScript.
En quoi WebAssembly rend alors JavaScript et les autres technologies du web plus performantes ?
Grâce à Web Assembly il est maintenant possible d’exécuter du code compilé, issu d’autres langages tel que C, C++, C# ou encore Rust, qui sont des langages plus optimisés pour effectuer certaines tâches. Ainsi, il nous est possible d’écrire un code en JavaScript qui utilise du code C compilé en .wasm, qui viendra remplacer les portions de code « chaudes » qui étaient précédemment compilées, optimisées, désoptimisées, et recompilées par le JIT.
De plus, grâce à leurs petites tailles, les fichiers .wasm sont très peut coûteux à être importés et donc ne créent pas de latence supplémentaire.

Pour finir, on peut trouver une autre application à Web Assembly en dehors de la recherche de performances. En effet, puisqu’il est maintenant possible d’exécuter du code C, C++, C#, Rust… pour le web, il n’est plus nécessaire de réécrire du code en JavaScript si une alternative dans un autre langage existe déjà, et a déjà prouvé son efficacité. Permettant ainsi de faciliter le travail des développeurs et de mettre en place un « pont » entre les langages, au service du web.

II. SMART CONTRACTS

1. BLOCKCHAIN & SMART CONTRACTS

« Une blockchain est une base de données décentralisée publique. » Expliquons rapidement cette phrase.
Tout d’abord, afin de comprendre pourquoi nous parlons de décentralisation, il faut comprendre ce qu’est un « tier de confiance ». Un « tier de confiance » est une personne (morale ou non) qui est chargée d’assurer un service entre deux personnes. Par exemple, la banque est le tier de confiance utilisé pour une transaction monétaire, mais encore, quand vous souhaitez accéder à vos données stockées dans le cloud, vous faites appel à un tier de confiance (par exemple Amazon) qui vous assure de stocker vos informations et de vous permettre d’y accéder. Le système basé sur les tiers de confiances est ce qu’on appelle un système « centralisé ». En effet, une banque, ou une ferme de serveurs, se charge de centraliser les transactions ou le stockage des données.
Ainsi, l’objectif de la décentralisation est de se passer de ces tiers de confiance. Pour ce faire, la blockchain est manipulée par des centaines de milliers de personnes, qui possèdent tous un même registre. Ensuite, afin de modifier ce registre, pour inscrire une nouvelle information, l’entièreté des personnes qui contribuent à ce registre doivent valider la modification. Le registre est alors décentralisé, puisqu’il n’est plus géré par une unique entité.
De plus, quand on parle de blockchain, on parle de base de données publique. En effet, une blockchain n’est ni plus ni moins qu’un registre informatique où l’on peut stocker des informations de manière sécurisée. Ainsi, par sa propriété à être décentralisée, ce registre est public, n’importe quelle personne peut venir consulter les informations qu’il contient, le stocker et contribuer aux validations des prochaines modifications.
Un smart contract ou « contrat intelligent », pour sa part, est un contrat passé entre deux entités, inscris de manière immuable dans la blockchain. Il permet de jouer le rôle des tiers de confiance dans un système centralisé. En effet, un smart contract n’est ni plus ni moins qu’un code informatique se trouvant dans une blockchain, qui fixe le cadre d’un contrat. Il définit les actions à réaliser, lorsque les conditions voulues par les parties l’ayant signé sont respectées. Ils sont aujourd’hui écrits dans des langages de programmations tel que Solidity, qui sont basés sur JavaScript.

2. UTILISATION DE WEBASSEMBLY POUR ECRIRE DES SMART CONTRACTS

Tout d’abord, les langages tel que Solidity sont des langages pensés pour être exécutés sur la blockchain. En effet, la blockchain impose plusieurs contraintes au langage, qui ont forcé les développeurs à concevoir des langages spécifiques pour y répondre. Parmi ces contraintes, les deux plus importantes sont :
- La nécessité d’avoir un programme peu couteux en stockage.
o En effet plus les fichiers sont volumineux, plus ils sont coûteux à inscrire dans la blockchain.
- La nécessité d’avoir des programmes exécutables sur n’importe quelle machine.
o En effet, comme expliqué précédemment, la blockchain peut être stockée par n’importe quel individu. Ainsi, les programmes des smart contracts doivent pouvoir s’exécuter sur la machine de ces individus, quelle que soit leur architecture.
Cependant, les langages comme Solidity répondent à ces exigences, mais font face à d’autres problèmes. En effet, ces langages sont peu performants, et surtout spécifiques à l’utilisation sur une bolckchain. Cette spécificité implique le besoin d’une main d’œuvre qualifiée dans un domaine « de niche ».
C’est à ce moment que Web Assembly trouve toute son application pour les smart conrtacts. En effet, comme nous l’avons vu précédemment, les fichiers .wasm sont des fichiers peu coûteux en stockage, et exécutables sur toutes les architectures machines. WebAssembly répond ainsi aux exigences de la blockchain, mais plus encore.
WebAssembly permet d’obtenir un fichier .wasm à partir d’autres langages de haut niveau. Ainsi, cela permet d’ouvrir la programmation de smart contracts à d’autres langages de programmation. Permettant alors d’avoir accès à une main œuvre qualifiée beaucoup plus grande, mais également à des langages plus performants et optimisés pour effectuer certaines tâches.
WebAssembly semble donc être le futur des smart contracts et permettra sans aucun doute, comme elle le fait avec les technologies du web, d’ouvrir de nouvelles possibilités aux smart contracts.

VT2022 XXX fiche

2022-11-28T15:21:52Z

Martin.Verrier: Blanked the page

VT2022

2022-11-28T15:21:23Z

Martin.Verrier: /* Séance 4 : 28/11 */

[[VT2021|<< Etudes 2021]] [[VT|Sommaire]] [[VT2023|Etudes 2023 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en INFO5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.

Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Chaque séance comporte 3 à 4 présentations suivi chacune d'une démonstration. Chaque présentation dure entre 20 et 25 minutes en fonction des séances. Pour plus de sécurité, la démonstration peut être pré-enregistrée.

Votre présentation sera réalisée de préférence avec [[reveal.js]] ou avec [[remarkjs]].

Votre présentation sera notée et commentée par tous vos camarades via un sondage (smartphone). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu en vaut-il la chandelle ?

[[File:presentation-VT-INFO5-2122.pdf|transparents d'introduction à l'UE]]

=Planning=

== Séance 1 : 07/11 (réporté)==

== Séance 2 : 14/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

Présentation et organisation.

== Séance 3 : 21/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[AdTech et Surveillance capitalism]]: Julien Guigard, Angelo Alibert [[Media:VT2022_Adtech_presentation.pdf|présentation]], [[VT2022_Adtech_fiche|fiche]], [[VT2022_Adtech_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Oeuvres d'art générées par une IA]] : DALL-E 2, Midjourney et Stable Diffusion : Kacha, Jardin [[Media:VT2022_AIArt_presentation.pdf|présentation]], [[Media:VT2022 AIArt synthese.pdf|fiche]], [[VT2022_AIArt_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Ansible]]: Da Costa [[Media:VT2022_Ansible_presentation.pdf|présentation]], [[VT2022_Ansible_fiche|fiche]], [[VT2022_Ansible_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 4 : 28/11 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[Web Assembly et Smart Contracts]]: Verrier, Mottino [[Media:VT2022_WebAssemblyEtSmartContracts_presentation.pdf|présentation]], [[VT2022_WebAssemblyEtSmartContracts_fiche|fiche]], [[VT2022_WebAssemblyEtSmartContracts_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[GPT Neo|GPT la suite]] : Monthe Djeumou, Simo Yokam [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Implants rétiniens]]: Bernerd, NGuyen Justin [[Media:VT_Implants_Rétiniens.pdf|présentation]], [[Media:Fiche_de_synthèse.pdf|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 5 : 05/12 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* WebRTC: Hadiby, Mohsen [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Voice-First Development : Designing, Developing, and Deploying Conversational Interfaces: Conjard, Fodor [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Helium: Lavirotte, Pelisse [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Internet of Audio Things]]: Teyssier, Drouin [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 6 : 12/12 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* NVidia [[Deep learning super sampling (DLSS)]]: Canin, Wagner [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* OpenPose (ou autre): Poitevin, Reygner [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* AzureRTOS: Bach, Chiotti [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Post-quantum cryptography]] : Zhang, Guiguis [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 7 : 09/01 ==
Enseignants : [[User:Donsez|Didier Donsez]]

* Vote électronique : Abecassis [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* NFT : plateformes, technologies, vices et vertus: Faghloumi [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* Géo-localisation Wifi : Fournier [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Generation of ASMR (Autonomous sensory meridian response)]]: Chappaz, De Oliveira [[Media:VT2022_ASMR_presentation.pdf|présentation]], [[VT2022_ASMR_fiche|fiche]], [[VT2022_ASMR_demo|demo]], [https://montube.com/AZERTYUIO screencast]

== Séance 8 : 16/01 (très probablement en distanciel) ==
Enseignants : [[User:Donsez|Didier Donsez]]

* [[IPFS (InterPlanetary File System)]]: Capet, Royer [[Media:VT2022_XX_presentation.pdf|présentation]], [[VT2022_XXX_fiche|fiche]], [[VT2022_XXX_demo|demo]], [https://montube.com/AZERTYUIO screencast]
* [[Low Code Development]] : Breton, Nguyen Clément [[Media:VT2022_LowCode_presentation.pdf|présentation]], [[Media:VT2022_LowCode_fiche.pdf|fiche]], [[Media:VT2022_LowCode_demo.pdf|demo]], [https://montube.com/AZERTYUIO screencast]

=Sujets=
# [[Oeuvres d'art générées par une IA]] : DALL-E 2, Midjourney et Stable Diffusion
# [[GPT Neo]]
# [[Predictive networks]]
# [[Objectives and Key Results]]
# [[Implants rétiniens]]
# [[Post-quantum cryptography]]
# [[Internet of Audio Things]]
# [[uFS]] : a user-level filesystem semi-microkernel
# [[Generation of ASMR (Autonomous sensory meridian response)]]
# [[Wasm|WebAssembly]]
# [[Web Assembly et Smart Contracts]]
# [[Application Performance Monitoring]] : démonstration de [[Apache Skywalking]]
# [[Low Code Development]]
# [[Multi-Region Database Deployments: Patterns and Anti-Patterns]] : démonstration avec [[Cockroack]]
# [[Proof of Coverage Blockchain]] : démonstration d'[[Helium]]
# [[IPFS (InterPlanetary File System)]]
# [[Géolocalisation Wifi : principles et services de géolocalisation Wifi et cellulaire]]
# [[Caches distribués]]: démonstration avec [[Redis]]
# [[NEMU]] : open source hypervisor specifically built and designed to run modern cloud workloads on modern 64-bit Intel and ARM CPUs.
# [[Fission]] : open-source serverless function framework for [[Kubernetes]] with a focus on developer productivity and high performance.
# [[AdTech et Surveillance capitalism]]
# [[Conflict-free replicated data type]] (CRDT)
# [[ Voice-First Development]] : Designing, Developing, and Deploying Conversational Interfaces
# [[AzureRTOS]] : système d'exploitation pour l'Internet des Objets. démonstration sur [https://www.st.com/en/evaluation-tools/b-l475e-iot01a.html B-L475] à récupérer au fablab.
# Algorithmes et systèmes de vote électronique : vices et vertus.
# [[Pantavisor Linux]]: A Framework for Building Containerized IoT Systems
# [[WebRTC]] : Web Real-Time Communication
# [[uFS]] : a user-level filesystem semi-microkernel
# [[Bundle Protocol]]
# [[NFT]] : plateformes, technologies, vices et vertues.
# [[MLOps]] : DevOps for Machine Learning projects

File:VT2022 XX presentation.pdf

2022-11-28T14:02:29Z

Martin.Verrier:

VT2022 XXX fiche

2022-11-28T13:31:58Z

Martin.Verrier:

VT2022 XXX fiche

2022-11-28T13:31:28Z

Martin.Verrier:

VT2022 XXX fiche

2022-11-28T13:30:17Z

Martin.Verrier:

##Résumé

WebAssembly, est un format d'instruction binaire basé sur une machine à pile. Cette technologie permet entre autres de compiler du code de n’importe quel langage en fichier .wasm. Ces fichiers binaires sont alors très peu coûteux en stockage, et peuvent être exécutés sur n’importe quelle architecture machine, mais également intégrés à du code JavaScript par exemple. Cela permet aux technologies du web de pouvoir exécuter du code déjà compilé, provenant d’autres langages, pouvant être plus performants pour certaines tâches.
Cette technologie peut alors parfaitement s’intégrer à la blockchain, afin de coder des smart contracts plus performants. En effet, les programmes des smart contracts ont besoin de répondre à deux problématiques majeures, qui sont la taille du fichier, et la possibilité d’exécuter ces programmes sur n’importe quelle architecture machine.
WebAssembly répond à ces critères, et permet d’écrire des smart contracts dans des langages performants tel que C, C++, C# ou encore Rust. Cela semble alors être une technologie révolutionnaire pour le milieu des smart contracts.

##Abstract

WebAssembly is a binary instruction format based on a stack machine. This technology allows, among other things, to compile code of any language into .wasm files. These binary files are then very cheap in storage, and can be executed on any machine architecture, but also integrates well with JavaScript code for example. This allows web technologies to run already compiled code from other languages, which can be more efficient for certain tasks.
This technology can then be perfectly integrated with the blockchain, in order to propose more efficient smart contracts. Indeed, smart contract programs need to answer two major issues, which are the file size, and the possibility to run these programs on any machine architecture.
WebAssembly meets these criteria, and allows to write smart contracts in powerful languages such as C, C++, C# or even Rust. It seems then to be a revolutionary technology for the smart contract community.

##WebAssembly

1. ETAT DES TECHNOLOGIES DU WEB AVANT WEBASSEMBLY

On observe deux phases importantes dans l’évolution des technologies du web, et plus particulièrement de JavaScript.
Au tout début, le langage JavaScript était exécuté via un interpréteur. Cet interpréteur permet de se passer du temps de compilation d’un fichier (par opposition au compilateur) et donc de gagner en performance. En effet, pour rappel, à l’inverse d’un compilateur qui va traduire l’ensemble du code en langage machine avant l’exécution, l’interpréteur traduit uniquement la ligne qu’il est en train d’exécuter, et exécute ainsi le programme ligne par ligne.
Cependant, cette méthode a ses limites et a amené les technologies du web à évoluer, vers ce que nous allons appeler la phase 2, avec l’utilisation des compilateurs Just-In-Time (JIT).
En effet, l’utilisation de l’interpréteur pose plusieurs soucis de performances. Imaginons que vous rechargiez une page web, le code devra alors être de nouveau exécuté entièrement par l’interpréteur. Alors que si nous avions compilé le code via un compilateur lors de la première itération, nous n’aurions qu’à exécuter le code précédemment compilé directement. Ce problème de réinterprétation du code peut également survenir dans les boucles, où nous pourrions simplement compiler la ligne de code qui sera exécutée plusieurs fois, plutôt que de l’interpréter à chaque tour de boucle.
Oui mais, changer pour une utilisation du compilateur à la place de l’interpréteur ferait perdre en performance dans le cas où nous utilisons des pages statiques. C’est pourquoi, le compilateur JIT a été inventé pour résoudre ce problème.
Comment fonctionne un compilateur JIT ?
Un compilateur Just-In-Time fonctionne de la même manière qu’un interpréteur, à la différence qu’il va compiler certaines portions de code au cours de l’exécution. En effet, lors de l’exécution d’un programme il va identifier si une portion de code « chauffe » beaucoup ou non, et décider de compiler ces portions de code en fonction de leur état. On dit alors que du code chauffe s’il est interprété plusieurs fois (dans une boucle par exemple). Ainsi les portions de code qui chauffent seront compilées et stockées, afin de pouvoir exécuter directement le code compilé lors de sa prochaine exécution. De plus, afin d’optimiser la compilation, le JIT fais des hypothèses sur le code compilé, comme par exemple le type des variables.
Comme vous le savez peut-être, JavaScript est un langage non typé, et peut donc contenir des structures de données avec des types non homogènes. Ainsi, le JIT va faire une hypothèse sur le type des données traités lors de la compilation. Ainsi, lors de la prochaine exécution il vérifiera si son hypothèse est juste avant d’exécuter le code compilé. Si jamais son hypothèse est fausse, il va alors faire une « désoptimisation » en supprimant le code compilé. L’exécution sera alors assurée par l’interpréteur, et peut être plus tard recompilé à nouveau suivant de nouvelles hypothèses.

2. WEB ASSEMBLY

Avec l’arrivée du compilateur JIT, les performances du Web ont explosé, avant de de nouveau stagner (état des technologies actuelles). C’est pourquoi, les grandes entreprises telles que Google, Mozilla, Apple, Microsoft et W3C ont commencé à travailler sur une nouvelle technologie : WebAssembly, pour répondre aux nouvelles problématiques de performances.
En effet, le problème que pose aujourd’hui le JIT est la grande perte de performance lors de l’étape d’optimisation du code compilé et la désoptimisation, étapes qui peuvent se répéter indéfiniment. Ainsi, l’objectif de WebAssembly est de supprimer cette étape.
Pour ce faire, WebAssembly permet de générer des fichiers binaires .wasm qui peuvent être obtenus en compilant n’importe quel langage de programmation en .wasm. WebAssembly est une machine à pile, c’est-à-dire que les fichiers binaires générés ne stockent pas les registres dont sont issus les données pour effectuer les calculs. Cela permet entre autres de produire des fichiers très légers, qui sont alors rapidement transférables et peu gourmands en stockage. De plus, ces fichiers peuvent être ensuite exécutés sur n’importe quelle architecture de machine. Grâce à sa compatibilité avec toutes sortes de langages, les modules .wasm peuvent, par exemple, alors être intégrés à du code JavaScript.
En quoi WebAssembly rend alors JavaScript et les autres technologies du web plus performantes ?
Grâce à Web Assembly il est maintenant possible d’exécuter du code compilé, issu d’autres langages tel que C, C++, C# ou encore Rust, qui sont des langages plus optimisés pour effectuer certaines tâches. Ainsi, il nous est possible d’écrire un code en JavaScript qui utilise du code C compilé en .wasm, qui viendra remplacer les portions de code « chaudes » qui étaient précédemment compilées, optimisées, désoptimisées, et recompilées par le JIT.
De plus, grâce à leurs petites tailles, les fichiers .wasm sont très peut coûteux à être importés et donc ne créent pas de latence supplémentaire.

Pour finir, on peut trouver une autre application à Web Assembly en dehors de la recherche de performances. En effet, puisqu’il est maintenant possible d’exécuter du code C, C++, C#, Rust… pour le web, il n’est plus nécessaire de réécrire du code en JavaScript si une alternative dans un autre langage existe déjà, et a déjà prouvé son efficacité. Permettant ainsi de faciliter le travail des développeurs et de mettre en place un « pont » entre les langages, au service du web.

##Smart contracts

1. BLOCKCHAIN & SMART CONTRACTS

« Une blockchain est une base de données décentralisée publique. » Expliquons rapidement cette phrase.
Tout d’abord, afin de comprendre pourquoi nous parlons de décentralisation, il faut comprendre ce qu’est un « tier de confiance ». Un « tier de confiance » est une personne (morale ou non) qui est chargée d’assurer un service entre deux personnes. Par exemple, la banque est le tier de confiance utilisé pour une transaction monétaire, mais encore, quand vous souhaitez accéder à vos données stockées dans le cloud, vous faites appel à un tier de confiance (par exemple Amazon) qui vous assure de stocker vos informations et de vous permettre d’y accéder. Le système basé sur les tiers de confiances est ce qu’on appelle un système « centralisé ». En effet, une banque, ou une ferme de serveurs, se charge de centraliser les transactions ou le stockage des données.
Ainsi, l’objectif de la décentralisation est de se passer de ces tiers de confiance. Pour ce faire, la blockchain est manipulée par des centaines de milliers de personnes, qui possèdent tous un même registre. Ensuite, afin de modifier ce registre, pour inscrire une nouvelle information, l’entièreté des personnes qui contribuent à ce registre doivent valider la modification. Le registre est alors décentralisé, puisqu’il n’est plus géré par une unique entité.
De plus, quand on parle de blockchain, on parle de base de données publique. En effet, une blockchain n’est ni plus ni moins qu’un registre informatique où l’on peut stocker des informations de manière sécurisée. Ainsi, par sa propriété à être décentralisée, ce registre est public, n’importe quelle personne peut venir consulter les informations qu’il contient, le stocker et contribuer aux validations des prochaines modifications.
Un smart contract ou « contrat intelligent », pour sa part, est un contrat passé entre deux entités, inscris de manière immuable dans la blockchain. Il permet de jouer le rôle des tiers de confiance dans un système centralisé. En effet, un smart contract n’est ni plus ni moins qu’un code informatique se trouvant dans une blockchain, qui fixe le cadre d’un contrat. Il définit les actions à réaliser, lorsque les conditions voulues par les parties l’ayant signé sont respectées. Ils sont aujourd’hui écrits dans des langages de programmations tel que Solidity, qui sont basés sur JavaScript.

2. UTILISATION DE WEBASSEMBLY POUR ECRIRE DES SMART CONTRACTS

Tout d’abord, les langages tel que Solidity sont des langages pensés pour être exécutés sur la blockchain. En effet, la blockchain impose plusieurs contraintes au langage, qui ont forcé les développeurs à concevoir des langages spécifiques pour y répondre. Parmi ces contraintes, les deux plus importantes sont :
- La nécessité d’avoir un programme peu couteux en stockage.
o En effet plus les fichiers sont volumineux, plus ils sont coûteux à inscrire dans la blockchain.
- La nécessité d’avoir des programmes exécutables sur n’importe quelle machine.
o En effet, comme expliqué précédemment, la blockchain peut être stockée par n’importe quel individu. Ainsi, les programmes des smart contracts doivent pouvoir s’exécuter sur la machine de ces individus, quelle que soit leur architecture.
Cependant, les langages comme Solidity répondent à ces exigences, mais font face à d’autres problèmes. En effet, ces langages sont peu performants, et surtout spécifiques à l’utilisation sur une bolckchain. Cette spécificité implique le besoin d’une main d’œuvre qualifiée dans un domaine « de niche ».
C’est à ce moment que Web Assembly trouve toute son application pour les smart conrtacts. En effet, comme nous l’avons vu précédemment, les fichiers .wasm sont des fichiers peu coûteux en stockage, et exécutables sur toutes les architectures machines. WebAssembly répond ainsi aux exigences de la blockchain, mais plus encore.
WebAssembly permet d’obtenir un fichier .wasm à partir d’autres langages de haut niveau. Ainsi, cela permet d’ouvrir la programmation de smart contracts à d’autres langages de programmation. Permettant alors d’avoir accès à une main œuvre qualifiée beaucoup plus grande, mais également à des langages plus performants et optimisés pour effectuer certaines tâches.
WebAssembly semble donc être le futur des smart contracts et permettra sans aucun doute, comme elle le fait avec les technologies du web, d’ouvrir de nouvelles possibilités aux smart contracts.

VT2022 XXX fiche

2022-11-28T13:29:26Z

Martin.Verrier: Created page with "Résumé WebAssembly, est un format d'instruction binaire basé sur une machine à pile. Cette technologie permet entre autres de compiler du code de n’importe quel langage..."

Résumé

WebAssembly, est un format d'instruction binaire basé sur une machine à pile. Cette technologie permet entre autres de compiler du code de n’importe quel langage en fichier .wasm. Ces fichiers binaires sont alors très peu coûteux en stockage, et peuvent être exécutés sur n’importe quelle architecture machine, mais également intégrés à du code JavaScript par exemple. Cela permet aux technologies du web de pouvoir exécuter du code déjà compilé, provenant d’autres langages, pouvant être plus performants pour certaines tâches.
Cette technologie peut alors parfaitement s’intégrer à la blockchain, afin de coder des smart contracts plus performants. En effet, les programmes des smart contracts ont besoin de répondre à deux problématiques majeures, qui sont la taille du fichier, et la possibilité d’exécuter ces programmes sur n’importe quelle architecture machine.
WebAssembly répond à ces critères, et permet d’écrire des smart contracts dans des langages performants tel que C, C++, C# ou encore Rust. Cela semble alors être une technologie révolutionnaire pour le milieu des smart contracts.

Abstract

WebAssembly is a binary instruction format based on a stack machine. This technology allows, among other things, to compile code of any language into .wasm files. These binary files are then very cheap in storage, and can be executed on any machine architecture, but also integrates well with JavaScript code for example. This allows web technologies to run already compiled code from other languages, which can be more efficient for certain tasks.
This technology can then be perfectly integrated with the blockchain, in order to propose more efficient smart contracts. Indeed, smart contract programs need to answer two major issues, which are the file size, and the possibility to run these programs on any machine architecture.
WebAssembly meets these criteria, and allows to write smart contracts in powerful languages such as C, C++, C# or even Rust. It seems then to be a revolutionary technology for the smart contract community.

WebAssembly

1. ETAT DES TECHNOLOGIES DU WEB AVANT WEBASSEMBLY

On observe deux phases importantes dans l’évolution des technologies du web, et plus particulièrement de JavaScript.
Au tout début, le langage JavaScript était exécuté via un interpréteur. Cet interpréteur permet de se passer du temps de compilation d’un fichier (par opposition au compilateur) et donc de gagner en performance. En effet, pour rappel, à l’inverse d’un compilateur qui va traduire l’ensemble du code en langage machine avant l’exécution, l’interpréteur traduit uniquement la ligne qu’il est en train d’exécuter, et exécute ainsi le programme ligne par ligne.
Cependant, cette méthode a ses limites et a amené les technologies du web à évoluer, vers ce que nous allons appeler la phase 2, avec l’utilisation des compilateurs Just-In-Time (JIT).
En effet, l’utilisation de l’interpréteur pose plusieurs soucis de performances. Imaginons que vous rechargiez une page web, le code devra alors être de nouveau exécuté entièrement par l’interpréteur. Alors que si nous avions compilé le code via un compilateur lors de la première itération, nous n’aurions qu’à exécuter le code précédemment compilé directement. Ce problème de réinterprétation du code peut également survenir dans les boucles, où nous pourrions simplement compiler la ligne de code qui sera exécutée plusieurs fois, plutôt que de l’interpréter à chaque tour de boucle.
Oui mais, changer pour une utilisation du compilateur à la place de l’interpréteur ferait perdre en performance dans le cas où nous utilisons des pages statiques. C’est pourquoi, le compilateur JIT a été inventé pour résoudre ce problème.
Comment fonctionne un compilateur JIT ?
Un compilateur Just-In-Time fonctionne de la même manière qu’un interpréteur, à la différence qu’il va compiler certaines portions de code au cours de l’exécution. En effet, lors de l’exécution d’un programme il va identifier si une portion de code « chauffe » beaucoup ou non, et décider de compiler ces portions de code en fonction de leur état. On dit alors que du code chauffe s’il est interprété plusieurs fois (dans une boucle par exemple). Ainsi les portions de code qui chauffent seront compilées et stockées, afin de pouvoir exécuter directement le code compilé lors de sa prochaine exécution. De plus, afin d’optimiser la compilation, le JIT fais des hypothèses sur le code compilé, comme par exemple le type des variables.
Comme vous le savez peut-être, JavaScript est un langage non typé, et peut donc contenir des structures de données avec des types non homogènes. Ainsi, le JIT va faire une hypothèse sur le type des données traités lors de la compilation. Ainsi, lors de la prochaine exécution il vérifiera si son hypothèse est juste avant d’exécuter le code compilé. Si jamais son hypothèse est fausse, il va alors faire une « désoptimisation » en supprimant le code compilé. L’exécution sera alors assurée par l’interpréteur, et peut être plus tard recompilé à nouveau suivant de nouvelles hypothèses.

2. WEB ASSEMBLY

Avec l’arrivée du compilateur JIT, les performances du Web ont explosé, avant de de nouveau stagner (état des technologies actuelles). C’est pourquoi, les grandes entreprises telles que Google, Mozilla, Apple, Microsoft et W3C ont commencé à travailler sur une nouvelle technologie : WebAssembly, pour répondre aux nouvelles problématiques de performances.
En effet, le problème que pose aujourd’hui le JIT est la grande perte de performance lors de l’étape d’optimisation du code compilé et la désoptimisation, étapes qui peuvent se répéter indéfiniment. Ainsi, l’objectif de WebAssembly est de supprimer cette étape.
Pour ce faire, WebAssembly permet de générer des fichiers binaires .wasm qui peuvent être obtenus en compilant n’importe quel langage de programmation en .wasm. WebAssembly est une machine à pile, c’est-à-dire que les fichiers binaires générés ne stockent pas les registres dont sont issus les données pour effectuer les calculs. Cela permet entre autres de produire des fichiers très légers, qui sont alors rapidement transférables et peu gourmands en stockage. De plus, ces fichiers peuvent être ensuite exécutés sur n’importe quelle architecture de machine. Grâce à sa compatibilité avec toutes sortes de langages, les modules .wasm peuvent, par exemple, alors être intégrés à du code JavaScript.
En quoi WebAssembly rend alors JavaScript et les autres technologies du web plus performantes ?
Grâce à Web Assembly il est maintenant possible d’exécuter du code compilé, issu d’autres langages tel que C, C++, C# ou encore Rust, qui sont des langages plus optimisés pour effectuer certaines tâches. Ainsi, il nous est possible d’écrire un code en JavaScript qui utilise du code C compilé en .wasm, qui viendra remplacer les portions de code « chaudes » qui étaient précédemment compilées, optimisées, désoptimisées, et recompilées par le JIT.
De plus, grâce à leurs petites tailles, les fichiers .wasm sont très peut coûteux à être importés et donc ne créent pas de latence supplémentaire.

Pour finir, on peut trouver une autre application à Web Assembly en dehors de la recherche de performances. En effet, puisqu’il est maintenant possible d’exécuter du code C, C++, C#, Rust… pour le web, il n’est plus nécessaire de réécrire du code en JavaScript si une alternative dans un autre langage existe déjà, et a déjà prouvé son efficacité. Permettant ainsi de faciliter le travail des développeurs et de mettre en place un « pont » entre les langages, au service du web.

Smart contracts

1. BLOCKCHAIN & SMART CONTRACTS

« Une blockchain est une base de données décentralisée publique. » Expliquons rapidement cette phrase.
Tout d’abord, afin de comprendre pourquoi nous parlons de décentralisation, il faut comprendre ce qu’est un « tier de confiance ». Un « tier de confiance » est une personne (morale ou non) qui est chargée d’assurer un service entre deux personnes. Par exemple, la banque est le tier de confiance utilisé pour une transaction monétaire, mais encore, quand vous souhaitez accéder à vos données stockées dans le cloud, vous faites appel à un tier de confiance (par exemple Amazon) qui vous assure de stocker vos informations et de vous permettre d’y accéder. Le système basé sur les tiers de confiances est ce qu’on appelle un système « centralisé ». En effet, une banque, ou une ferme de serveurs, se charge de centraliser les transactions ou le stockage des données.
Ainsi, l’objectif de la décentralisation est de se passer de ces tiers de confiance. Pour ce faire, la blockchain est manipulée par des centaines de milliers de personnes, qui possèdent tous un même registre. Ensuite, afin de modifier ce registre, pour inscrire une nouvelle information, l’entièreté des personnes qui contribuent à ce registre doivent valider la modification. Le registre est alors décentralisé, puisqu’il n’est plus géré par une unique entité.
De plus, quand on parle de blockchain, on parle de base de données publique. En effet, une blockchain n’est ni plus ni moins qu’un registre informatique où l’on peut stocker des informations de manière sécurisée. Ainsi, par sa propriété à être décentralisée, ce registre est public, n’importe quelle personne peut venir consulter les informations qu’il contient, le stocker et contribuer aux validations des prochaines modifications.
Un smart contract ou « contrat intelligent », pour sa part, est un contrat passé entre deux entités, inscris de manière immuable dans la blockchain. Il permet de jouer le rôle des tiers de confiance dans un système centralisé. En effet, un smart contract n’est ni plus ni moins qu’un code informatique se trouvant dans une blockchain, qui fixe le cadre d’un contrat. Il définit les actions à réaliser, lorsque les conditions voulues par les parties l’ayant signé sont respectées. Ils sont aujourd’hui écrits dans des langages de programmations tel que Solidity, qui sont basés sur JavaScript.

2. UTILISATION DE WEBASSEMBLY POUR ECRIRE DES SMART CONTRACTS

Tout d’abord, les langages tel que Solidity sont des langages pensés pour être exécutés sur la blockchain. En effet, la blockchain impose plusieurs contraintes au langage, qui ont forcé les développeurs à concevoir des langages spécifiques pour y répondre. Parmi ces contraintes, les deux plus importantes sont :
- La nécessité d’avoir un programme peu couteux en stockage.
o En effet plus les fichiers sont volumineux, plus ils sont coûteux à inscrire dans la blockchain.
- La nécessité d’avoir des programmes exécutables sur n’importe quelle machine.
o En effet, comme expliqué précédemment, la blockchain peut être stockée par n’importe quel individu. Ainsi, les programmes des smart contracts doivent pouvoir s’exécuter sur la machine de ces individus, quelle que soit leur architecture.
Cependant, les langages comme Solidity répondent à ces exigences, mais font face à d’autres problèmes. En effet, ces langages sont peu performants, et surtout spécifiques à l’utilisation sur une bolckchain. Cette spécificité implique le besoin d’une main d’œuvre qualifiée dans un domaine « de niche ».
C’est à ce moment que Web Assembly trouve toute son application pour les smart conrtacts. En effet, comme nous l’avons vu précédemment, les fichiers .wasm sont des fichiers peu coûteux en stockage, et exécutables sur toutes les architectures machines. WebAssembly répond ainsi aux exigences de la blockchain, mais plus encore.
WebAssembly permet d’obtenir un fichier .wasm à partir d’autres langages de haut niveau. Ainsi, cela permet d’ouvrir la programmation de smart contracts à d’autres langages de programmation. Permettant alors d’avoir accès à une main œuvre qualifiée beaucoup plus grande, mais également à des langages plus performants et optimisés pour effectuer certaines tâches.
WebAssembly semble donc être le futur des smart contracts et permettra sans aucun doute, comme elle le fait avec les technologies du web, d’ouvrir de nouvelles possibilités aux smart contracts.