IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Pourquoi devriez-vous faire migrer vos sites statiques de HTTP vers HTTPS ?
Voici les raisons avancées par un expert en sécurité Web

Le , par Bill Fassinou

142PARTAGES

16  0 
En mai dernier, Google avait annoncé comment l’adoption par défaut de HTTPS en lieu et place de HTTP se ferait sur son navigateur Chrome. On apprenait donc que Chrome n’allait bientôt plus afficher le label « Sécurisé » pour les sites HTTPS. Au lieu de ça, le navigateur estampillera systématiquement tous les sites HTTP comme étant non sécurisés. Cette modification traduit les efforts constants de Google depuis plusieurs années pour faire passer Internet sous HTTPS. Le moins que l’on puisse dire, c’est que cette préoccupation qui amène l’entreprise à vouloir sécuriser Internet est partagée par plus d’un. Troy Hunt, un éminent expert australien connu pour ses activités de sensibilisation sur des sujets liés à la sécurité, fait partie de ceux qui, comme Google, estiment que la migration vers HTTPS est plus que nécessaire.

En effet, déjà en janvier dernier, l’expert australien avait expliqué que l’adoption de HTTPS avait dépassé le « point de basculement » et « deviendrait très prochainement la norme ». Ses dires semblent réellement se vérifier puisque depuis janvier, le pourcentage de pages Web chargées sur HTTPS est passé de 52 % à 71 %. La proportion du million de sites le plus important du monde redirigeant les utilisateurs vers HTTPS serait également passée de 20 % à presque 50 %.


Cette adoption générale plutôt rapide a été motivée par la recrudescence d’avertissements sur les navigateurs (Chrome et Firefox, principalement), des certificats plus facilement accessibles et une prise de conscience grandissante des internautes concernant les risques inhérents à la navigation non sécurisée. S’intéressant au cas des sites Web statiques, l’expert australien s’est attelé à répondre aux nombreuses questions qui se posaient çà et là sur la pertinence d’employer une connexion HTTPS pour ce type de sites.

Afin donc de démontrer que même les sites statiques ont besoin de HTTPS, il a patiemment attendu de recevoir une invitation à essayer de hacker un site statique qui, selon son administrateur, est à l'abri des risques inhérents à http sans pour autant utiliser le protocole HTTPS, mais il en a reçu une autre à la place. Celle d’intercepter le trafic transmis via une connexion non sécurisée de son propre site afin d’expliquer la nécessité de sécuriser aussi les sites statiques.

C’est donc ce qu’il a fait. Il a intercepté son propre trafic et assemblé une série de démos dans une vidéo de 24 minutes expliquant pourquoi HTTPS est nécessaire sur les sites Web statiques. Il a donc mené une attaque sur son propre trafic prouvant ainsi encore plus le caractère insécurisé des sites HTTP. Il a employé comme point d’accès sans fil, un petit équipement (le WiFi Pineapple) pour inciter les appareils à le considérer comme un point d'accès connu auquel ils peuvent se connecter automatiquement sans intervention de l’utilisateur.

Il a également montré que les sites http sont vulnérables face aux tentatives de détournement de DNS. Pour preuve, l’expert australien en a exécuté un juste avec quelques lignes de FiddlerScript, une des fonctionnalités les plus puissantes de Fiddler (une application de serveur proxy de débogage HTTP) qui permet d’améliorer l’interface utilisateur de Fiddler, d’ajouter de nouvelles fonctionnalités et de modifier les requêtes et les réponses « à la volée » pour introduire tout comportement souhaité.

Ainsi, il a donc pu générer un trafic provenant d'une adresse totalement différente à partir du trafic allant à une adresse non sécurisée. Troy Hunt a remarqué que le même résultat pouvait être obtenu en utilisant DNSspoof. Il a également remarqué que ce même résultat peut encore être obtenu grâce à une attaque CSRF contre un routeur.

Les avis des internautes sur la question semblent assez hétéroclites. Quatre grands courants de pensée se dégagent des rangs des détracteurs de la migration vers HTTPS. Il y a ceux qui voient derrière HTTPS un complot pensé par les géants d’Internet avec à leur tête Google ; ceux qui, malgré la possibilité d’obtenir des certificats gratuits via Let’s Encrypt et Cloudflare, trouvent que la migration vers HTTPS coûte « trop cher » ; ceux qui trouvent que l’implémentation du protocole HTTPS est trop compliquée et trop chronophage ; et enfin ceux qui pensent qu’il n’y a aucun intérêt à adopter un protocole de sécurité qui ne peut pas garantir une protection parfaite et impénétrable à 100 % 24/7.

Source : Billet de blog

Et vous ?

Qu’en pensez-vous ?
HTTPS est-il réellement selon vous le prochain stade de l’évolution d’Internet ? Pourquoi ?

Voir aussi

Chrome : Google a décidé de marquer tous les sites HTTP comme non sécurisés la mesure prendra effet au mois de juillet

Firefox se prépare à son tour à marquer les sites en HTTP comme étant non sécurisés, une représentation visuelle est déjà disponible sur la Nightly

Chrome ne va plus afficher le label « Sécurisé » pour les connexions HTTPS à compter de septembre 2018

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Neckara
Inactif https://www.developpez.com
Le 04/09/2018 à 10:17
Citation Envoyé par Paul TOTH Voir le message
rien n'empêche Wikipedia de fonctionner en HTTP en lecture seule et de basculer en HTTPS pour les mises à jour.
Et comment tu t'assures de l'intégrité de l'information sur le réseau ?

Un petit MITM, et paff, on te modifie à la volée les pages qui te serons envoyées... c'est pas sensible ça peut-être ?

Et c'est bien beau de basculer de HTTP à HTTPS lors de la connexion... tu vas sérieusement vérifier qu'il y a bien le petit cadenas à chaque authentification, sans jamais te tromper ?

Citation Envoyé par Paul TOTH Voir le message
Le navigateur pourrait aussi s'assurer que les ressources HTTP et HTTPS soient isolées afin de pouvoir mettre toutes les ressources statiques en HTTP (images, CSS, ...) et les données vives et sensibles en HTTPS (html, js) en laissant évidement le choix au développeur de savoir ce qui est sensible et ce qui ne l'est pas.
Si on peut jouer avec le CSS, il y a de quoi s'amuser pour défacer le site... ne serait-ce que cacher tous les éléments de la page et n'afficher qu'une image comme fond de body.

Apparemment, on peut même exécuter du JS via du CSS.

Citation Envoyé par Paul TOTH Voir le message
Et de façon générale, l'affirmation de Dave la plus vraie et que mettre un panneau "DANGER" sur un site HTTP est tout aussi absurde que mettre "SECURE" sur un site HTTPS....
Au niveau comportemental, les deux ne sont absolument pas équivalent.

Citation Envoyé par Paul TOTH Voir le message
notamment depuis l'existence de Let's Encrypt qui permet d'avoir un certificat valide pour un site web quelconque en 10 secondes montre en main (et je sais de quoi je parle).
Que cela se fasse en 10 secondes ou en 10 ans, cela ne change rien quant au fait que non-seulement le medium de communication sera sécurisé, et que tu auras l'assurance de bien communiquer avec le site affiché, la seule faille restante étant le typosquatting et l'inattention de l'utilisateur. Derrière, d'autres solutions techniques existent.

Citation Envoyé par Paul TOTH Voir le message
Et taguer "DANGER" sur tous les sites HTTP historiques qui sont en ligne depuis 20 ans est tout aussi absurde...
Parce que la sécurité d'un site se mesure à la durée de son existence ???

Tu vas me dire qu'un vieux site pourri non-mis à jour depuis 20 ans, tournant sur un serveur perdu au fin fond de je-ne-sais-où, avec un OS et un serveur web obsolète, etc. est plus sécurisé qu'un site plus récent comme e.g., le site de ma banque ?

Citation Envoyé par Paul TOTH Voir le message
si Google veux sécuriser ces sites (qu'il indexe déjà), qu'il en prenne une empreinte, si celle-ci ne bouge pas, c'est qu'il est tout aussi secure qu'avant.
Donc on ne peut plus mettre à jour sa page, ni même avoir un site un peu dynamique ?

Sérieusement, c'est dingue d'entendre de telles bêtises sur un forum de développeur informatique.
3  0 
Avatar de Neckara
Inactif https://www.developpez.com
Le 04/09/2018 à 19:26
Citation Envoyé par Paul TOTH Voir le message
de la même façon qu'en HTTPS qui ne préserve pas de l'attaque MIM
Depuis quand TLS est vulnérable aux attaques MITM ?

Alors certes il peut y avoir des attaques :
  • si les serveurs et clients ne sont pas à jour, sont mal configurés, et/ou proposent des ciphers_suites trop faibles ;
  • si le navigateur ou l'ordinateur de l'utilisateur sont corrompus ;
  • si un CA/Root CA est corrompu ;
  • en cas de typosquatting, ou d’inattention de l'utilisateur.


Encore que dans certains cas, il existe des solutions techniques qui peuvent se rajouter à HTTPS, comme des white/blacklists, utiliser des marques-pages, mettre à jour son navigateur régulièrement, etc.

Mais de là à dire que HTTP est au même niveau que HTTPS au niveau de l'intégrité des données… faut pas déconner.
On ne fait pas du TLS over HTTP, juste pour le plaisir de rajouter un S à HTTPS.

Citation Envoyé par Paul TOTH Voir le message
ce n'est pas un choix de l'utilisateur, mais du serveur


Ce que je suis en train de te dire c'est qu'il suffit d'un simple MITM sur la version HTTP du site pour récupérer les identifiants et mots de passes de l'utilisateur qui aura oublié de regarder la présence du cadena avant de se connecter.

Citation Envoyé par Paul TOTH Voir le message
tu me fais une démonstration ?
C'est la base (de tête) :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
* {
    display: none
}

body {
   background-url: .....;
   display: block;
   // tu rajoutes 2-3 options pour rendre le tout joli.
}
Citation Envoyé par Paul TOTH Voir le message
et HTTPS ne t'en préserve pas non plus
À partir du moment où tu ne peux pas injecter arbitrairement du contenu… ben si.

Citation Envoyé par Paul TOTH Voir le message
mais HTTPS n'a jamais voulu dire "site de confiance" !
Qui te parle de "site de confiance" ?
On ne te donne qu'une indication sur la sécurité du médium de communication, et que tu es bien en train de discuter avec la "bonne personne" !

Pour le reste, c'est d'autres protocoles qui entrent en jeu, que ce soit des systèmes de réputations/black-lists, de la détection de comportements malicieux, etc.

Citation Envoyé par Paul TOTH Voir le message
sauf que si je hack un site, il me faut 10 secondes pour activer mon propre certificat dessus et détourner www.nabamque-en-ligne.com sur ce faut site sans le moindre warning HTTPS.
???

Oui, les serveurs peuvent se faire hacker, c'est pas nouveau. Et oui, quand le serveur est hacké, c'est déjà perdu.
Par contre, je ne comprends pas pourquoi tu veux rajouter ton propre certificat, plutôt que d'utiliser celui du serveur hacké.
Mais oui, tu peux obtenir des certificats pour un serveur sur lequel tu as la main, très étonnant n'est-ce pas ?

Et bientôt tu vas reprocher à HTTPS de ne pas vérifier que le site ne revends pas tes informations personnelles, ou que son propriétaire paye bien ses impôts ???

Citation Envoyé par Paul TOTH Voir le message
un site qui n'a pas bougé depuis 20 ans, il est sur depuis 20 ans, ou pas, mais ce statut n'a pas changé.
????

On s'en tape que son statut change ou non, ce qui nous intéresse, c'est qu'au moment où on le consulte, on puisse jouir d'un minimum de sécurité !

Citation Envoyé par Paul TOTH Voir le message
[…]je dis que les sites HTTP ne sont pas des dangers potentiels […]
À se demander pourquoi on a inventé TLS, à se demander pourquoi la confidentialité et l'intégrité des communications étaient importantes.
À se demander même à quoi sert la vie privée.

C'est vrai que c'est tellement pas un danger de télécharger des fichiers sans être sûr de son intégrité, c'est tellement pas un danger de lire des informations modifiées de manière malicieuse (e.g. commandes shell dangereuses, mauvais conseils, informations ou affirmations pouvant porter atteinte au propriétaire du site), c'est tellement pas un danger de pouvoir injecter de manière arbitraire des liens (e.g. un lien d'authentification), c'est tellement pas un danger de pouvoir rediriger tout le trafic vers un autre site, etc. etc.

Citation Envoyé par Paul TOTH Voir le message
ce qui serait bien c'est d'avancer des éléments techniques probants...HTTPS ne permet pas de s'assurer de la nature du site sécurisé, uniquement qu'il possède un certificat, et Let's Encrypt s'assure simplement que le demandeur est en mesure de mettre à jour le site...ce que sait faire tout hacker par définition.
Si le hacker a la main sur le serveur il peut en faire (plus ou moins) ce qu'il veut banane. Tu peux payer un certificats des millions d'euros, te faire prendre tes empreintes, te faire enfoncer une sonde anale, si un hacker pénètre sur ton serveur, il réutilise ton certificat et tu l'auras dans le cul, pas besoin d'en redemander un autre.

Citation Envoyé par Paul TOTH Voir le message
Du coup dire HTTP = DANGER, HTTPS = SECURE c'est trop binaire pour refléter la réalité.
Parce qu'on parle du médium de communication.

Et justement, le but de Chrome est de dire HTTP = DANGER, et HTTPS = rien. C'est à dire de prévenir l'utilisateur en cas de danger, plutôt que de lui confirmer une sécurité.
4  2 
Avatar de ALT
Membre émérite https://www.developpez.com
Le 07/09/2018 à 17:34
Bon, deux choses à mon avis :
  1. le coiffeur, il peut tout aussi bien se faire pirater en HTTP qu'en HTTPS.
  2. Je m'occupe d'un site purement informatif & statique, mis à jour par mes soins deux fois par an, sans inscription ni consultation d'une quelconque base de données. Quelqu'un peut-il m'expliquer à quoi peut me servir le HTTPS ?

Voilà. C'était ma contribution du jour au débat.
2  0 
Avatar de
https://www.developpez.com
Le 03/09/2018 à 16:23
Citation Envoyé par archqt Voir le message
Pourquoi y a besoin d'une service de certification ? Il suffit juste que le site donne à l'utilisateur la clé publique et ensuite quand l'utilisateur (le navigateur donc) dialogue avec le site, celui-ci utilise la clé privée pour retrouver es informations en clair et "amorcer" ensuite un dialogue en clé symétrique ?
Ce n'est pas suffisant, il faut pouvoir garantir que la clé publique que l'utilisateur reçoit appartient bien au site visité, ce qui n'est possible que via une autorité certifiante.
1  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 07/09/2018 à 12:02
Je n'ai pas le temps de développer mais en gros il faut compter 50% pour la même chose en HTTPS plutôt que HTTP

Peu efficient donc dangereux
ça ce n'est pas "Non consequitur". Apparemment vous ne vous êtes pas encore interrogé sur les questions de l'énergie et je vous rassure vous n'êtes pas le seul.
Tout ce que l'on fait demande de l'énergie (principe assez basique de physique). Tout ce que l'on fait d'inutile consomme donc inutilement de l'énergie. or l'énergie (que va consommer un serveur ou que va consommer la fabrication et la gestion de la vie de ce serveur et des ses composants) on la prélève à la nature d'une manière ou d'une autre et cela a des conséquences pour notre planète et par voie de conséquence pour nous. C'est donc bien dangereux. Le HTTPS du site du coiffeur n'est pas un détail, c'est un des grammes qui font la tonne.

Après la question de ce qui est inutile ou pas est un autre débat mais dans l'exemple, tout ce qui va alourdir les échanges entre un client et son serveur aura un coût pour la planète totalement inutile si le HTTPS n'est pas justifié.
Et comme vous le dites ça s'applique à beaucoup de choses.
Par exemple : Écouter de la musique sur Youtube c'est du HTTPS (inutilement, sans doute uniquement parce que sinon on dirait oha youtube ils sont pas https ) mais le problème n'est pas le HTTPS ici, c'est d'héberger et faire transiter sur le réseau un énorme flux vidéo (très souvent une image fixe) alors que l'on est là pour écouter un minuscule flux audio.
1  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 07/09/2018 à 12:24
Rendez vous en retard..
Citation Envoyé par Neckara Voir le message
Pour la latence... franchement ce qui prends le plus de temps, c'est généralement la limite des navigateurs quant au nombre de connexions simultanées ouvertes en même temps.
C'est marrant, j'ai un site HTTPS qui se charge en 1/4 de secondes pour la première page, et est instantanée pour les autres.
C'est pas parce qu'avec un bon serveur c'est pas trop génant que ca n'implique pas beaucoup plus d'infrastructure. un site HTTP ca tourne sur un microcontrôleur 8bit à 8MHz qui consomme 5mW, du HTTPS sur une telle machine c'est inenvisageable.

Citation Envoyé par Neckara Voir le message

Sur une connexion HTTPS, on est de l'ordre de la millisecondes, c'est invisible pour l'utilisateur.
et en plus c'est faux, il y a plusieurs échanges en HTTPS, qui chacuns sont plus longs que ça

Citation Envoyé par Neckara Voir le message

Ton coiffeur ne va pas auto-héberger son propre serveur... aujourd'hui HTTPS est totalement transparent, car géré par l'hébergeur.
en quoi que ce soit autohebergé ou hébergé par un hébergeur change quoi que ce soit ? au final le chiffrage il faudra le calculer, les données supplémentaire il faudra les transmettre... au final il y a plus de travail à fournir en HTTPS qu'en HTTP (plus de travail = plus d’énergie nécessaire), peu importe qui se charge de ça.

Citation Envoyé par Neckara Voir le message

[*]installer un faux module de payement ;
Et pourquoi le module de paiement ne serait pas juste lui en HTTPS ? (utile/pas utile au cas par cas...)

Citation Envoyé par Neckara Voir le message
[*]insérer des phrases du type : "on ne coiffe pas les juifs" ;
[*]insérer des conseils dangereux : "pour votre shampoing, mélanger du sodium pur dans l'eau".
[*]défacer le site pour insérer des spams : "enlarge your ponytail".
on a des autorités pour ça, pas besoin de pourrir l'environnement pour un hypothétique problème pour lequel on a le droit qui gère(ou peut gérer) très bien. Ça c'est typiquement du pas utile;
Pour le sodium j'ai le regret de constater que l'on trouve aujourd'hui un paquet de conseils débiles en HTTPS sur le net

Citation Envoyé par Neckara Voir le message
Pour les machines, cela demande une augmentation de combien de % du "nombre" de serveurs ou de ses capacités ?
50% comme je le disais (faut aller voir l'ADEME ou le GIEC pour avoir des infos sur ce genre d’études). Et faisant du HTTPS et FTPS sur microcontrôleur je peux garantir que ce 50% n'est pas sur estimé, perso j'aurais dit bien plus que ça vu comme mes équipements sont archis larges sans TLS et au bord de l'explosion en TLS... Pour mes développements embarqués cette surconsommation pose notamment des gros soucis d'autonomie, preuve que ça doit consommer plus (et bien plus que 50% en embarqué puisque plus difficile à optimiser)

Citation Envoyé par Neckara Voir le message

Après, je pense qu'on aura aussi fort à faire avec le coût des blockchains, la publicité/trackers, dimensionnement des images, streaming, etc.
c'est malheureusement encore pire que le surcout du HTTPS en effet
1  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 07/09/2018 à 16:07
Citation Envoyé par Neckara Voir le message
D'ailleurs si on voulait pinailler, ce ne serait plutôt néfaste que dangereux.
si c'est dangereux. https://www.larousse.fr/dictionnaire...s/danger/21607
on est en plein dedans.

Je résume ta position en "on s'en cogne de réfléchir à la pertinence du truc parce qu'à mon niveau suffit de cocher une case". Sauf que mon coiffeur il a une chance sur 45646545646546545645645645646546544654465465 d’être ennuyé, que les moyens de paiement son assurés pour ça et que non seulement le coiffeur il sen fout surement d'avoir un site sécurisé parce qu'il y connait rien mais que par contre il a des enfants et a peut être pas envie de contribuer à leur laisser un monde moisi.

Le principe d'imposer une arme de guerre (HTTPS) pour écraser une mouche (l'ombre de la sécurité et de la confidentialité) est fondamentalement un principe stupide (https://www.larousse.fr/dictionnaire...=stupide#74100) ou pire démagogique ou surement un peu des 2 vu qu'il y a probablement un lobby derrière ça.
1  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 07/09/2018 à 19:39
Citation Envoyé par Neckara Voir le message

Derrière, la partie la plus importante en terme de bande passante a besoin de HTTPS : téléchargements, communications (e-mail, chats, voix), etc.
Si les sites auxquels on pourrait éventuellement retirer HTTPS sont négligeables face à cela, le gain sera négligeable. Ce sera juste des efforts et donc de l'énergie gaspillée pour rien.
oui c'est certain, des trucs comme youtube ont absoluement besoin de HTTPS, et/ou ca représente rien en terme de flux...

Citation Envoyé par Neckara Voir le message

HTTPS coûte pratiquement rien en terme utilisateur, c'est dérisoire.
je n'arrive pas à comprendre ce que tu ne comprends pas. A partir du moment ou le HTTPS est activé tout ce qui passera demandera plus de ressources, l'utilisateur a rien à voir là dedans, c'est un choix de conception.
1  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 09/09/2018 à 22:23
j'ai des systèmes qui transmettent en clair, d'autres en TLS, d'autre en TLS avec authentification du client (ca ca sert pour des trucs éparpillés dans la nature). en radio, en Ethernet, en RS485, en GSM, en SMS aussi (beurk mais ça dépanne), ou qui ne communiquent pas.

mes µC qui gèrent du TLS consomment beaucoup plus par ce qu'ils s'allument beaucoup plus longtemps que les autres pour communiquer.
en veille ils tirent tous à peu près pareils suivant ce qu'ils ont autour, mais pour les équipement sur batterie c'est de l'ordre de 10µA en 1.8 ou 3V,. En run pour causer ca dépend des technos radi mais le CPU lui va tirer une 10n de mA sous 1.8 ou 3v. on est loin des 100mA sous 5v au repos d'une PI (+ les 200mA d'une SD )
une carte µC en série industrie fonctionnent sans soucis jusqu'à 80° (faut réfléchir un peu à son environnement quand même...) et en séries spéciales on peut aller au delà. j'ai fait du 150° pour une applis tordue une fois (avec un peu de perte au feu au sens propre )
La dissipation thermique du CPU est important quand ça peu fausser les mesures du truc à coté.

pour les micro pc, les plus robuste que j'ai vu sont les orange pi. plusieurs sont équipés de EMMC http://www.orangepi.org/

Le problème des certificats coté client est bien connu, notamment sur les réseaux d'énergie, il y a eu quelques soucis de datalogger qui se sont fait accéder en direct sur le terrain. mes trucs sont fait pour gérer ça. mais c'est super lourdingue à gérer (reprogrammation du µc pour modifier le certificat avec gestion d'un protocole ad hoc pour faire ce chargement sans risque de vol). mais dans certains cas c'est justifié par les enjeux autour des décisions prises avec ces données.
1  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 10/09/2018 à 0:19
je vends des systèmes mais à la base je travaille sur la performance des outils de production, mon boulot m'oblige à collecter de la donnée la plupart du temps mais la forme peut être très variées;
1)-déjà beaucoup (trop) de datas disponibles => travail de compilation et d'analyse de donnée
2)-pas tout ce qu'il faut, notamment ce qui concerne l'énergie => compagne ponctuelle, souvent sans transmission de donnée, pour me retrouver au final dans le cas 1) Dans ce contexte là je transmets de la donnée surtout quand les accès sont difficiles, qu'il y a risque important de défaillance des capteurs et/ou que la campagne ne peut pas être reproduite en cas de problème de mesure et de mauvaise surprise à la fin.
3)-déjà beaucoup de boulot de fait sur le process et un projet d'industrialisation de l'analyse de donnée apparait et là il y a souvent travail avec des informaticiens et une grosse campagne de POC(s) pour tester et valider les outils mis en place avant passage très couteux des automaticiens (automaticiens tellement couteux et peu habitués aux mesures dispersées qu'on me demande de déployer mes outils, ceux qui sont conçus pour rester à demeure).

La 5G est sur le papier très intéressante. Elle devrait mettre à la retraite les trucs très à la mode aujourd'hui comme lora et Sigfox mais de toute manière suivant les applis il faudra toujours jongler entre pleins de technos, les contraintes d'environnement, les débits de donnée à passer, les coûts unitaires, les possibilités d’administration, les contraintes d'alimentations...
Dans tous les cas quand on peut passer par des bus de terrain filaires ou de l’Ethernet on se porte beaucoup mieux. c'est une misère de déployer de la radio et quand il faut de l'autonomie ça ne fonctionne que pour des périodes d’émission très lente (genre le 1/4 d'heure). Quand il faut aller vite il y a le filaire ou le datalogger silencieux, éventuellement équipé de radio pour transmettre un diagnostique ou des alarmes et/ou des infos partielles.
1  0