Les capteurs ("sensors") sont les briques de ce que l'on appelle à tort l'IoT ("Internet of Things"), comme si c'était une fatalité que ces objets communiquent par Internet. Il n'en est rien et ils communiquent en général au premier niveau par des réseaux dédiés, les LPWAN ("Low Power WAN"). Le sujet étant particulièrement vaste, nous nous attachons à expliquer ce que sont les capteurs dans leur infinie diversité, ce qu'ils mesurent et il nous faudra nous souvenir de quelques principes de physique, que nous avons peut-être oubliés. Nous nous intéressons aux architectures de mises en œuvre et plus précisément aux niveaux "edge", pour aller du capteur aux systèmes centraux de consolidation, ainsi qu'aux langages à connaître et aux API les plus pratiquées. La grande nouveauté est paradoxalement le retour en arrière. Car les capteurs sont souvent de petits équipements, avec peu de mémoire et de faibles capacités de stockage. De sorte que si l'on veut leur confier une partie des traitements : filtrages, contrôle de premier niveau, etc, il nous faudra réapprendre des principes d'économie et ne plus nous répandre sur 32 Gbytes, dès lors que nous aurons une addition à faire. C'est un monde nouveau qui s'ouvre, avec ses bonnes pratiques, ses OS temps réel et ses contraintes de sécurité. Mais c'est aussi une respiration nouvelle pour les développeurs et responsables d'infrastructures, qui vont retrouver de l'intérêt à leur métier.

Mais il a aussi pour objet de passer en revue les différentes architectures auxquelles on peut se référer pour distribuer les applications dans un contexte d'éclatement du code et des données. Le problème est beaucoup plus délicat à traiter qu'auparavant et il nous faut choisir les solutions les mieux adaptées en fonction de critères tels que les temps d'arrêt supportable des applications, la sécurité des opérations et la simplicité de réalisation. Il est question de déploiements en mode "récréation", "bleu-vert", "Canary", etc, des appellations exotiques qui cachent une redoutable complexité de mise en œuvre. Le tout pour aboutir à la contrainte ultime qui est celle du déploiement continu et en temps réel. Etant entendu que tout doit être pris en compte, l'intégration pour les développeurs, autrement dit la phase amont du processus, puis les livraisons et déploiement, selon la distinction "subtile" qu'en font les agilistes. On n'oubliera pas que chaque méthode induit ses propres procédures de tests, de construction des exécutables ("build"), de gestion des versions, etc. Cette petite révision nous a semblé nécessaire.