Syndiquer le contenu
Mis à jour : il y a 7 heures 52 min

Un système d’exploitation français pour la souveraineté numérique

7 février, 2016 - 15:48

C’est passé à l’Assemblée nationale française (en attendant le Sénat), au sein d’un texte comportant plusieurs volets : l’État français veut se doter d’un système d’exploitation afin d’obtenir une certaine souveraineté numérique. Le texte vise à la production d’un rapport envisageant la « possibilité créer un Commissariat à la souveraineté numérique » et précisant « les conditions de mise en place, sous l’égide de ce commissariat, d’un système d’exploitation souverain » (article 16 ter dans la version adoptée à l’Assemblée nationale).
Si le sujet suscite des critiques, la France n’est pas le seul pays à vouloir en quelque sorte protéger sa souveraineté numérique. Il y a des précédents, tous basés sur GNU/Linux. Tour d’horizon en seconde partie.

Des précédents en France

Déjà l’année dernière, on avait assisté à la création d’un Institut pour la souveraineté numérique. Le Conseil national du numérique, lors d’une de ses sessions de travail, avait abordé cette thématique. Même si la tentation est forte de dire que GNU/Linux serait la solution, ce n’est pas si évident.

L’opérateur télécom Orange avait déjà envisagé d’avoir son propre système d’exploitation en 2010 (et avait sorti sa tablette Tabbee sous GNU/Linux). Et le ministre français de l’Économie, du Redressement productif et du Numérique, Arnaud Montebourg, avait déjà évoqué un système d’exploitation bleu, blanc, rouge en 2014 (en se basant sur le concept de « résogiciel français » du président de Skyrock, Pierre Bellanger).

Ajoutons qu’il existe déjà un système « souverain » CLIP, basé sur GNU/Linux et développé par l’ANSSI depuis 2005, pour les opérateurs d’importance vitale (OIV), prévu pour des cas d’usage spécifiques et pas pour une utilisation par le grand public ou les administrations en général. Il est « en phase préliminaire de déploiement ».

Des précédents dans d’autres pays

D’autres pays ont déjà créé des distributions pour garantir leur indépendance. En Espagne, l’Andalousie produit GuadaLinex et l’Argentine propose Huayra (ces deux distributions sont basées sur Debian). L’article de ZDNet cite aussi la Chine, l’Inde, le Brésil et la Turquie.

On notera que tout le monde semble avoir opté pour une base GNU/Linux. Est‐ce que la souveraineté numérique peut exister en dehors de Linux ? C’est le sujet de la dissertation à laquelle vous allez participer par vos commentaires.

Et des critiques de toute part

Le Monde rappelle que « La secrétaire d’État au numérique “ne croit pas à la possibilité d’un système d’exploitation souverain, qui serait peu opérant” » et des députés de la majorité et de l’opposition l’ont qualifié d’« erreur » et de « ridicule ». Et le directeur général de l’ANSSI l’a qualifié de « non‐sens » et refuser l’idée d’un système noyauté (« plein de saletés ») pour les services de renseignement.

Les critiques sont nombreuses : travail gigantesque, coût exhorbitant, usine à gaz en préparation, lubie du made in France, fiascos précédents dans le secteur éducatif français et du « cloud souverain », railleries multiples via Twitter.

En tout cas le projet de loi « Économie : pour une République numérique » a permis d’évoquer largement les logiciels libres au sein de l’Hémicycle.

Télécharger ce contenu au format Epub

Lire les commentaires

Firefox 44 débarque

7 février, 2016 - 11:32

Firefox 44 a débarqué le 26 janvier 2016 (NdA : 44, débarquer, toussa…). Nous proposons dans cette dépêche les nouveautés pour les versions de bureau et mobile, ainsi que pour les développeurs.

NdA : nous avons toujours besoin de toute aide afin de publier régulièrement les dépêches liées aux sorties de Firefox, rendez-vous sur l’espace de rédaction collaborative de LinuxFr.org (linuxfr.org/redaction).

Sommaire Firefox bureau

Commençons par ce qui ne change finalement pas : depuis la version précédente, seules les extensions signées par Mozilla sont acceptées par le navigateur. Ce comportement peut toutefois être désactivé à l’aide d’un réglage du navigateur qui devait disparaître avec la présente version. La suppression de ce réglage est repoussée.

NB : La décision de n’accepter que les extensions signées dans Firefox, pour des raisons de sécurité selon Mozilla, fait débat parmi les utilisateurs de Firefox, et ce jusque dans les rangs de la distribution GNU/Linux Fedora. Elle a été temporairement désactivée dans le paquet.

Quelques améliorations :

  • amélioration de la page d’avertissement dans les cas d’erreurs de certificats et de connexions non certifiées ;
  • lecture des vidéos avec le codec H.264 sous GNU/Linux lorsque FFmpeg est disponible ;
  • lecture des vidéos en WebM/VP9 sur les systèmes d’exploitation qui n’intègrent pas le MP4/H.264 ;
  • dans la chronologie de l’inspecteur d’animation, l’icône éclair à côté des animations tourne dans la partie compositeur ;
  • pour les connexions HTTPS seulement, les données peuvent être compressé avec la bibliothèque Brotli. Ce format de compression est en cours de normalisation au sein de l’IETF (plus d’informations) ;
  • les commandes de capture d’écran permettent le choix du rapport d’aspect de pixel dans les outils développeurs ;
  • la gestion des fontes web sous Linux utilise désormais le même code que sur les autres plates‐formes ;
  • utilisation d’une signature électronique SHA-256 pour les versions destinées à Windows afin de suivre les nouvelles recommandations pour les signatures ;
  • validation plus stricte des polices web ;
  • désactivation du clavier à l’écran pour Windows 8 et Windows 8.1.
Firefox Mobile

Quelques améliorations :

  • Les utilisateurs peuvent maintenant choisir une page d’accueil à afficher au démarrage au lieu du panneau Top Sites ;
  • Ajout de la prise en charge des URI avec le protocole mms: ;
  • Page des comptes Firefox basée sur le web ;
  • Montrer les suggestions d’historique de recherche ;
  • Demander aux utilisateurs avant d’ouvrir une URI d’Intent dans un onglet de navigation privée ;
  • Onglets améliorés sur les téléphones ;
  • Utilisation du service d’impression Android pour la possibilité d’impression dans le cloud.
Changements commun au bureau et Android Améliorations pour les développeurs

Au menu :

  • un clic droit sur un objet journalisé dans la console permet de le stocker comme une variable globale sur la page ;
  • nouvel outil de mémoire pour inspecter le tas ;
  • API pour les Services Workers ;
  • lecteur de JSON intégré pour voir, rechercher, copier et sauver intuitivement les données sans extensions ;
  • sauter aux définitions de fonctions dans le débogueur avec Cmd-Clic ;
  • extension et API de débogage des WebSockets ;
  • la vue des règles montre désormais les styles en utilisant le texte de leur auteur, et les éditions dans la vue des règles sont désormais liées à l’éditeur de style ;
  • obligation des signatures d’extensions.

Outils visuels pour Animation :

  • visualiser et éditer les règles d’animations CSS keyframes directement depuis l’inspecteur ;
  • modifier visuellement les courbes cubic-bezier qui dirigent la manière dont les animations progressent à travers le temps ;
  • découvrir et inspecter les animations CSS et les transitions jouées dans la page ;
  • pour en savoir plus, rendez‐vous sur http://devtoolschallenger.com/.

Outils visuels pour les mises en forme et les styles :

  • montrer les règles dans la vue (?) pour vérifier la taille et la position et utiliser l’outil de mesure pour facilement détecter les problèmes d’espacement et d’alignement ;
  • utiliser les filtres CSS pour prévisualiser et créer des effets temps réel comme les drop-shadows, sépia, etc. ;
  • en apprendre plus : http://devtoolschallenger.com/.
Prochaines versions Firefox 46

Poursuite de la mise en avant des connexions HTTPS : si vous entrez un couple identifiant/mots de passe sans passer par TLS, Firefox 46 affiche une alerte (voir la page informative anglophone).
[Crédit NextInpact]

Firefox 46 acceptera les préfixes webkit (bug 1213126). On ne dira pas merci aux webmestres qui ne se préoccupent que des iPhones et nuisent à l’interopérabilité (Microsoft avec Edge a dû faire les mêmes concessions).

Firefox 48 et suivants

Les WebExtensions vont descendre progressivement dans Firefox, à partir de la version 45 et avec la version 48 pour objectif (vous pouvez suivre l’avancement du projet). Rappelons qu’elles sont déjà à l’honneur dans Firefox OS 2.5.

Mozilla travaille à l’intégration de l’API Web Speech, logiquement l’approche est un peu moins centralisée que dans Chrome (voir la traduction du billet).

WebGL 2 arrive dans Firefox Nigtly, faites chauffer vos GPU ;-)

La navigation classique pourrait bénéficier de la même option de protection contre le traçage que celle introduite dans la version 42 au sein de la navigation privée, voir bug 1231359 et bug 1231373.

Firefox (Bureau et Android) permettait de lancer des pseudo-applications qui s'appuient sur Firefox pour fonctionner, ce mode WebRT pourrait être retiré. Avec le retrait de Firefox OS du monde des ordiphones, c'est l'idée que le HTML pourrait servir de base à tout programme qui est moins promue chez Mozilla.

Pendant ce temps là, chez Mozilla…

La feuille de route de Servo a été mise à jour en ce début d’année. Il se dit par ailleurs dans les milieux autorisés que le maintien de la prise en charge de Windows XP par Firefox repousse l’intégration de morceaux de Servo dans ce dernier (processus nommé Oxidation), « vu que le support de Windows XP par Rust n’est pas complet ».

Télécharger ce contenu au format Epub

Lire les commentaires

Présentation technique de Canopsis

7 février, 2016 - 10:41

Supervision et visualisation des données : des domaines de l'informatique qui nous permettent de surveiller, analyser une infra, des données afin de comprendre et éventuellement prédire des dysfonctionnements.

De nombreux outils existent et excellent dans chacune de ces tâches. Les accorder ensemble afin d'unifier l'information permet ainsi de faciliter la prise de décision.

C'est ce que l'on appelle l'hypervision.

Canopsis se veut une solution d'hypervision (on évite l'appellation hyperviseur qui reste dans le langage courant spécifique à la virtualisation). Solution open-source sous licence AGPL3 développée par la société française Capensis, elle se veut simple d'utilisation, et suffisamment souple pour répondre à un maximum de besoin.

Sommaire La problématique

Dans une infra hétérogène, on dispose de nombreuses sources d'information :

  • côté supervision, on peut avoir un mélange de :
    • Nagios/Icinga
    • Centreon
    • Shinken
    • HPOV
    • Zabbix
    • SNMP
  • côté récolte de données, on peut avoir :
    • CollectD
    • Logstash
    • Munin
    • Telegraf (de la pile TICK)
  • ou encore :
    • des logs
    • des données stockées en base de données
    • un résultat de tests unitaires et fonctionnels (jMeter, Sikuli…)

La mise en place d'un accès à l'ensemble de ces informations peut être fastidieuse, et dans la plupart des cas, l'utilisateur (l'administrateur technique et/ou fonctionnel) devra accéder à plusieurs interfaces et maîtriser plusieurs outils.

Cela empêche d'avoir une vue d'ensemble cohérente et rend difficile l'anticipation ainsi que la prise de décision.

Objectif : la solution

C'est là que Canopsis intervient.

Étape 1 : les connecteurs

Dans un premier temps, nous devons récupérer les informations produites par cet ensemble hétérogène.

Ainsi, pour chaque source de données, nous sommes en mesure de développer un connecteur, capable d'extraire les informations voulues, et de les transmettre à Canopsis sous la forme d'événements standardisés.

Un certain nombre de connecteurs sont déjà disponibles sur le Gitlab.

Le cas le plus simple est donc celui ci :

#!/usr/bin/env python from time import time # lib qui nous permet de nous connecter au bus de données (cf étape 2) from kombu import Connection # module qui sera utilisé pour envoyer les événements from kombu.pools import producers # construction de l'événement selon le standard Canopsis event = { "timestamp": int(time()), # émetteur de l'événement "connector": "myconnector", "connector_name": "myconnector-instance0", # nature de l'événement "event_type": "check", # source de l'événement "source_type": "resource", "component": "<hostname>", "resource": "<job's name>", # données portées par l'événement "state": 0, # 0 = INFO, 1 = MINOR, 2 = MAJOR, 3 = CRITICAL "output": "<message>" } # construction de la routing_key, qui sert à identifier l'événement et à le router routing_key = "{0}.{1}.{2}.{3}.{4}".format( event['connector'], event['connector_name'], event['event_type'], event['source_type'], event['component'] ) if event['source_type'] == "resource": routing_key = "{0}.{1}".format( routing_key, event['resource'] ) # Connexion uri = 'amqp://cpsrabbit:canopsis@localhost:5672/canopsis' with Connection(uri) as conn: # Création de l'émetteur with producers[conn].acquire(block=True) as producer: # Publication producer.publish( event, serializer='json', exchange='canopsis.events', routing_key=routing_key )

Bien évidemment, du moment qu'un connecteur envoie ses événements, il peut être développé dans n'importe quel langage, c'est le cas du connecteur Nagios qui se présente comme un Nagios Event Broker, et est donc développé en C.

Étape 2 : le bus de données et les moteurs

Les événements produits par les connecteurs sont transmis au bus de données de Canopsis, basé sur RabbitMQ.

Source : http://igm.univ-mlv.fr/~dr/XPOSE2011/rabbitmq/usages.html

Ces événements vont être consommés par des daemons que nous appelons moteurs.

Leur but est simple :

  • traiter la donnée
  • enregistrer les informations pertinentes en base de données
  • transmettre, si nécessaire, l'événement à un ou plusieurs autres moteurs

Nous avons, par exemple :

  • le moteur event_filter qui se charge de filtrer/modifier les événements entrants
  • le moteur context qui se charge d'enregistrer les informations sur l'entité cible de l'événement (connecteur source, composant/ressource qui a produit l'événement…)
  • le moteur perfdata qui s'occupe d'historiser les données de performance (comme remontées par Nagios ou CollectD)

Comme pour les connecteurs, les moteurs peuvent être développés dans n'importe quel langage, bien que pour le moment nous les avons tous faits en Python.

Étant un daemon, un moteur dispose de 2 fonctions :

  • une pour consommer les événements (dans un thread à part)
  • une pour exécuter une tâche régulièrement (recharger la configuration, envoyer des stats…)

Ainsi que la configuration suivante :

[engine:myengine] # chemin Python de la méthode de consommation event_processing=canopsis.myfeature.process.event_processing # chemin Python de la méthode exécutée régulièrement beat_processing=canopsis.myfeature.process.beat_processing # nom de l'exchange AMQP sur lequel écouter (par défaut: amq.direct) exchange_name=canopsis.event # RK à consommer routing_keys=nagios.#,shinken.# # intervalle entre 2 exécutions du beat_processing (en secondes) beat_interval=60 # liste des moteurs sur lesquels retransmettre l'événement reçu, possiblement modifié (par défaut: aucun) next=myengine2,myengine3

Et donc l'implémentation se résume à :

def event_processing(engine, event, **_): # traiter l'événement return event def beat_processing(engine, **_): # faire des choses Étape 3 : les schémas

Toutes les données qui véhiculent dans le bus et qui sont sauvegardées en base sont munies de schémas les décrivant.

Ces schémas servent à plusieurs choses :

  • valider que la donnée est bien formatée
  • décrire comment la donnée sera représentée
  • décrire comment la donnée sera éditée

Ces deux derniers points permettent de générer une partie du code de l'UI (cf étape 5).

À terme, ils serviront également à :

  • décrire comment la donnée sera utilisée
  • décrire comment la donnée pourra être transformée

Ce qui permettra de générer une partie du code backend (cf étape 4).

Le formalisme qui permet d'écrire un schéma est actuellement inspiré du standard JSON Schema :

{ "title": "MyData", "description": "Schéma décrivant la donnée, comment l'afficher et l'éditer" // description de la donnée "type": "object", "properties": { "color": { "type": "string", "required": true, /* comment la donnée sera affichée/éditée * le rôle 'color' : * - affichera un carré de couleur lorsqu'on l'affichera * - affichera un colorpicker lorsqu'on l'éditera */ "role": "color", // les champs suivants servent pour le formulaire "title": "Couleur de la donnée", "description": "Tooltip d'aide" } }, // les champs suivants aident à générer le formulaire d'édition "categories": [ { "title": "General", "keys": ["color"] } ] }

L'id d'un schéma est construit de la manière suivante :

  • mydata
  • mydata.mydata2 : ici mydata2 hérite de mydata

On obtient donc en base de données :

{ "_id": "<id du schema>", "schema": // le schéma à proprement parler } Étape 4 : gérer et servir la donnée

Maintenant que nous avons la structure pour récupérer la donnée, et que nous sommes en mesure de la schématiser, il faut mettre en place les mécanismes permettant d'interagir avec et de la servir à l'UI.

A. Les managers

La gestion de la donnée est prise en charge par ce que l'on appelle les managers. Pour bien comprendre son rôle, il faut plonger un peu dans le code.

Un configurable est un objet Python dont les propriétés sont définies par son fichier de configuration :

from canopsis.configuration.configurable import Configurable from canopsis.configuration.configurable.decorator import conf_paths from canopsis.configuration.configurable.decorator import add_category from canopsis.configuration.model import Parameter CONF_PATH = 'myfeature/manager.conf' # {sys.prefix}/etc/{CONF_PATH} CATEGORY = 'MYFEATURE' # Définition du contenu de la catégorie CONTENT = [ Parameter('foo'), Parameter('bar', parser=int) ] # ajoute un fichier de configuration à lire par le configurable @conf_paths(CONF_PATH) # permet de spécifier la catégorie de configuration depuis laquelle on peut lire les paramètres @add_category(CATEGORY, content=CONTENT) class MyFeatureManager(Configurable): pass

Ainsi, avec le fichier de configuration suivant :

[MYFEATURE] foo=bar bar=42

Ou :

{ "MYFEATURE": { "foo": "bar", "bar": 42 } }

En effet, le configurable va tester différents drivers, actuellement on dispose de INI et JSON mais il est envisageable d'avoir un driver MongoDB ou autre

Lorsque l'on instanciera la classe, on obtiendra :

obj = MyFeatureManager() assert obj.foo == "bar" assert obj.bar == 42

Et à partir de cette classe Configurable on va définir l'arbre d'héritage suivant :

Un ConfigurableRegistry permet de spécifier, dans un paramètre de configuration, un autre Configurable à instancier :

otherconfigurable_value = canopsis.myotherfeature.manager.MyOtherFeatureManager

Et on y accèdera, dans l'instance, de la manière suivante :

assert isinstance(self['otherconfigurable'], MyOtherFeatureManager)

Le MiddlewareRegistry fait de même pour les Middleware (qui identifient un protocole ainsi qu'un type de données) :

mymiddleware_uri = protocol-datatype-datascope://

De même que pour le ConfigurableRegistry, on y accède de la manière suivante :

assert self['mymiddleware'].connected()

En général, un manager sera un MiddlewareRegistry, ce qui permettra de changer de techno utilisée, sans modifier le code :

[MYFEATURE] mystorage_uri = mongodb-timed-mydata:// # mystorage_uri = influxdb-timed-mydata:// mymanager_value = canopsis.myotherfeature.manager.MyOtherFeatureManager # mymanager_value = canopsis.myotherfeature.manager2.MyOtherFeatureManager2

Et ce manager sera utilisé par le moteur et le webservice.

En reprenant l'exemple du moteur :

from canopsis.common.utils import singleton_per_scope from canopsis.myfeature.manager import MyFeatureManager def event_processing(engine, event, manager=None, **_): if manager is None: # instancie la classe une seule fois par module manager = singleton_per_scope(MyFeatureManager) # faire des choses avec l'événement et le manager return event def beat_processing(engine, event, manager=None, **_): if manager is None: manager = singleton_per_scope(MyFeatureManager) # faire des choses avec le manager B. Les webservices

Afin de servir la donnée à l'UI, on dispose d'une application WSGI découpée en modules, que l'on appelle webservice.

Ces derniers se trouvent dans le paquet Python canopsis.webcore.services.

Et grâce au code suivant (à placer dans le __init__.py), on peut avoir plusieurs paquets Python fournissant du code à cet emplacement :

from pkgutil import extend_path __path__ = extend_path(__path__, __name__)

Bref, un webservice s'écrit très simplement :

# couche d'abstraction qui nous permettra de passer de Bottle à Flask from canopsis.common.ws import route from canopsis.common.utils import singleton_per_scope from canopsis.myfeature.manager import MyFeatureManager # Sera appelé par l'application WSGI pour charger les routes HTTP def exports(ws): # ici `ws` désigne donc le webserver manager = singleton_per_scope(MyFeatureManager) # ici on créé la route /foo qui accepte la méthode GET @route(ws.application.get) def foo(): return manager.foo # l'API retournera : # { # "total": 1, # "data": ["bar"], # "success": true # } # cette fois ci, on créé la route /bar/:baz @route(ws.application.get) def bar(baz): return (manager.bar == baz) Étape 5 : l'application web

Côté backend, on dispose désormais du nécessaire pour fournir à l'UI tout ce dont elle a besoin.
Ainsi, nous avons également travaillé la modularité de cette UI, basée sur Ember, au maximum.

A. Les briques

Afin de répondre à cette problématique de modularité, nous avons mis en place un système de briques, permettant de sélectionner les fonctionnalités effectivement chargées.

Concrètement, on peut voir une brique comme étant un addon apportant plusieurs fonctionnalités telles que :

  • nouveaux éléments graphiques (composants)
  • nouveaux outils de rendus (widgets, renderers)
  • nouveaux outils d'éditions (éditors)

Pour construire une brique, il suffit de créer un paquet NPM avec le package.json suivant :

{ "name": "<nom de la brique>", "description": "<description de la brique>", "version": "0.1.0", // il s'agit du fichier principal de la brique, il pointera vers la version de dev ou minifiée "main": "init.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "compile": "rm -Rf tmp/build && broccoli build tmp/build && cp tmp/build . -RT", "lint": "eslint src", "doc": "./node_modules/canopsis-ui-toolbelt/scripts/buildDoc", "minify": "node node_modules/canopsis-ui-toolbelt/scripts/minify.js" }, "repository": { "type": "git", "url": "<url du dépôt>" }, "author": "<auteur>", "license": "AGPL-3.0", "devDependencies": { "broccoli": "^0.16.9", "broccoli-funnel": "^1.0.1", "broccoli-merge-trees": "^1.0.0", "broccoli-sourcemap-concat": "^1.1.6", "broccoli-template": "^0.1.1", "broccoli-uglify-js": "^0.1.3", // outil de gestion des briques Canopsis "canopsis-ui-toolbelt": "https://git.canopsis.net/canopsis/canopsis-ui-toolbelt/repository/archive.tar.gz?ref=<branche git de canopsis-ui-toolbelt>", "jsdoc": "^3.3.0", "pre-commit": "^1.1.1" }, "pre-commit": [ "lint", "doc" ] }

Puis, dans un dossier src on placera le code source de la brique :

  • components/mycomponent/component.js
  • components/mycomponent/template.hbs
  • renderers/renderer-myrole.hbs
  • editors/editor-myrole.hbs
  • widgets/mywidget/controller.js
  • widgets/mywidget/mywidget.hbs
  • mixins/mymixin.js

L'outil canopsis-ui-toolbelt se charge de :

  • récupérer récursivement tout le code JS dans le dossier src
  • référencer le code JS dans le fichier init.js qui représente la brique
  • récupérer récursivement tout les templates (*.hbs) dans le dossier src
  • référencer les templates également dans le fichier init.js
  • référencer les templates dans Ember.TEMPLATES :
    • pour un composant, il est requis d'avoir le dossier components/<mycomponent>, afin que le template soit reconnu comme étant un template de composant
    • pour le reste, le nom du template dans Ember sera le nom du fichier sans extension

NB: Le découpage n'est donc obligatoire que pour les composants, le reste peut être mis en vrac dans src.

Une fois que l'on a créé tout cela (ou récupéré le dépôt Git), on peut finaliser la brique :

$ npm install $ npm run compile

Chaque fichier source contiendra au moins un Ember Initializer :

Ember.Application.initializer({ name: 'MyModule', after: ['Dependency1', 'Dependency2'], initialize: function(container, application) { var Dependency1 = container.lookupFactory('deptype:dependency1'), Dependency2 = container.lookupFactory('deptype:dependency2'); // do stuff application.register('modtype:mymodule', /* stuff */); } });

Cela permet ainsi de s'assurer du bon chargement de chaque module.

Au final, pour installer une brique, il suffit de :

  • cloner le dépôt finalisé dans : /opt/canopsis/var/www/canopsis
  • lancer la commande webmodulemanager enable mybrick afin de l'activer au chargement de l'UI

L'ensemble des briques existantes (hormis celle par défaut livrées avec Canopsis) sont disponible ici.

B. Les composants

Le composant, l'élément le plus basique de l'UI, sera utilisé par tout les autres éléments.
Il s'agit simplement d'un composant Ember avec un template à fournir.

On définira notre composant dans src/components/mycomponent/component.js :

Ember.Application.initializer({ name: 'MyComponent', after: [], initialize: function(container, application) { var MyComponent = Ember.Component.extend({ init: function() { this._super.apply(this, arguments); // faire des choses }, actions: { // on implémente les actions, déclenchable depuis le template foo: function() { alert('bar'); } } }); application.register('component:component-mycomponent', MyComponent); } });

Et le template dans src/components/mycomponent/template.hbs :

<h1>My awesome component</h1> <a {{action foo}}>Launch action</a> C. Les renderers/éditeurs

Une fois nos composants définis, on est en mesure de les utiliser dans des renderers ou des éditeurs.

Le but de ces éléments est simple :

  • lorsqu'on demande l'affichage d'une donnée avec le composant renderer :
    • le champ role du schéma JSON est également lu
    • si un renderer du même nom est trouvé, il est utilisé dans le template
    • sinon, on affiche la donnée telle quelle
  • lorsqu'un formulaire d'édition est généré à partir du schéma JSON, en utilisant le composant editor :
    • le champ role est lu
    • si un éditeur du même nom est trouvé, il est utilisé dans le formulaire
    • sinon, on utilise l'éditeur par défaut

Les renderers/éditeurs ne sont donc que de simple templates HTMLBars.

On aura le renderer dans src/renderers/renderer-myrole.hbs :

<p>My rendered data: {{value}}</p> {{component-mycomponent}}

Et l'éditeur dans src/editors/editor-myrole.hbs :

<p>My data is being edited :</p> {{input type="password" value=attr.value}} {{component-mycomponent}} D. Les widgets

Enfin, on aura les widgets, qui seront en mesure d'utiliser composants et
renderers afin d'implémenter des outils de visualisation de données plus complexes.

Un widget est un MVC complet :

  • on implémente un contrôleur
  • on implémente des mixins qui viendront s'appliquer à la vue
  • on écrit un template

Ce qui donne :

Ember.Application.initializer({ name: 'MyWidget', after: ['WidgetFactory'], initialize: function(container, application) { var WidgetFactory = container.lookupFactory('factory:widget'); var widgetOptions = {}; var MyWidgetViewMixin = Ember.Mixin.create({ didInsertElement: function() { this._super.apply(this, arguments); // faire des choses }, willDestroyElement: function() { this._super.apply(this, arguments); // faire des choses }, actions: { // actions de la vue } }); var widget = WidgetFactory('mywidget', { viewMixins: [ MyWidgetViewMixin ], actions: { // actions du contrôleur }, init: function() { // faire des choses }, findItems: function() { // méthode appelée lors de la récupération des données pour le template } }, widgetOptions); application.register('widget:mywidget'); } });

Ensuite, il est nécessaire de créer un schéma widget.mywidget.json qui sera utilisé pour configurer le widget lors de son ajout dans une vue :

{ "title": "MyWidget", "description": "Schéma de configuration de MyWidget", "metadata": { // icône dans le formulaire d'ajout de widget "icon": "fa fa-cog" }, "categories": [ { "title": "General", "keys": ["foo"] } ], "type": "object", "properties": { "foo": { "title": "Foo", // nom du champ dans le formulaire "description": "Foo field", // tooltip dans le formulaire "type": "string", "role": "myrole" } } } E. Les mixins

Lorsque l'on a des fonctionnalités communes à plusieurs widgets (comme le PeriodicRefresh qui actualise le widget régulièrement), il convient de factoriser le code en un mixin.

Ce dernier pourra être ajouté et configuré au widget via l'UI, et ensuite appliquer la-dite configuration au contrôleur du widget :

Ember.Application.initializer({ name:'MyMixin', after: ['MixinFactory'], initialize: function(container, application) { var Mixin = container.lookupFactory('factory:mixin'); var get = Ember.get; var MyMixin = Mixin('mymixin', { mixinsOptionsReady: function() { this._super.apply(this, arguments); var mixinOptions = get('mixinOptions.mymixin'); // faire des choses } }); application.register('mixin:mymixin', MyMixin); } });

Et il ne manque plus que le schéma mixin.mymixin.json décrivant la configuration du mixin :

{ "title": "MyMixin", "description": "Schéma de configuration de MyMixin", "metadata": { // description affiché dans l'UI "description": "Add stuff to widget" }, "categories": [ { "title": "General", "keys": ["bar"] } ], "type": "object", "properties": { "bar": { "title": "Bar", "description": "Bar field", "type": "string" } } } F. Les vues

Tout les outils sont désormais à notre disposition pour construire nos dashboards.

Donc si on résume :

  • une vue est composée de widgets
  • un widget est composé de composants et de mixins

L'UI fournit les outils qui permettent de construire ces vues, le résultat final est un document JSON stocké en base :

{ "_id": "id de ma vue", "description": "description de ma vue" "crecord_name": "nom de ma vue", "crecord_type": "view", "author": "<user qui a créé la vue>", "enable": true, "internal": false, "tags": [], // le widget initial de la vue "containerwidget": { // identifiant du widget "xtype": "widgetcontainer", "title": "container title vbox", // le widget "widgetcontainer" s'attend à avoir un champ "items" "items": [ { // le widget "widgetwrapper" sert à inclure des widgets dans un container pour les placer correctement "xtype": "widgetwrapper", "title": "wrapper", // le widget encapsulé : "widget": { "xtype": "mywidget", "title": "My awesome widget", // configuration spécifique au widget "foo": "bar", // mixins appliqués via l'UI : "mixins": [ { "name": "periodicrefresh", // paramètres du mixin "refreshInterval": 60 }, { "name": "mymixin", // paramètres du mixin "bar": "baz" } ] } } ], // le container de base de la vue à un widget de layout par défaut "mixins": [ { "name": "lightlayout" } ] } }

La totalité de l'UI est générée à partir de ces vues JSON, et est donc complètement personnalisable.

Le bac à événements

Parmi les vues par défaut qui sont livrées avec Canopsis, on trouve le Bac à événements.

Cette vue fournit un dashboard de supervision commun, unifiant ainsi la totalité des superviseurs remontant des informations à Canopsis.

Depuis ce bac, on voit apparaître les différentes alarmes avec comme informations :

  • leurs sources d'émission (le connecteur)
  • leurs sources cible (composant/ressource, qui dans la plupart des cas correspond au couple host/service)
  • le dernier message associé à un check (Nagios, Shinken, Centreon, …)
  • le statut de l'alarme associé au check :
    • Off : aucune alarme n'est présente
    • On Going : un problème a été remonté et n'est toujours pas résolu
    • Stealthy : une alarme a été remontée et est immédiatement repassée OK (durée paramétrable)
    • Flapping : il y a eu X changements d'état en 1h sur l'alarme (durée et fréquence paramétrable)
    • Cancelled : l'alarme a été annulée par un utilisateur (pour éviter les faux-positifs)
  • l'état du check :
    • INFO : tout va bien
    • MINOR : équivalent au Warning de Nagios
    • MAJOR : équivalent au Critical de Nagios
    • CRITICAL : les Unknown de Nagios sont remontés en tant que tel, mais cela ne se limite pas à cette notion
    • UNKNOWN : état non pris en charge à l'heure actuelle, c'est tout ce qui est supérieur à CRITICAL (3)
  • la présence d'un acquittement et/ou d'un ticket :
    • les connecteurs pour Nagios, Shinken, etc… peuvent remonter les acquittements posés
    • depuis Canopsis, on peut en poser manuellement
  • la date du dernier changement d'état

Sur chaque alarme, on peut réaliser différentes actions :

  • l'acquittement (permet de déverrouiller les autres actions), cela émettra le même événement qui serait remonté par un superviseur, soit un événement de type ack
  • une suppression de l'acquittement, cela émettra un événement de type ackremove
  • une annulation de l'alarme, cela émettra un événement de type cancel
  • une fois l'alarme annulée, on peut annuler cette action, cela émettra un événement de type uncancel
  • une déclaration de ticket :
    • cela émettra un événement de type declareticket
    • cet événement pourra être capturé par le moteur event_filter pour déclencher un job (voir plus bas) qui communiquera le ticket à un outil tiers (par exemple iTop)
  • une association de ticket existant :
    • cela émettra un événement de type assocticket
    • on peut imaginer que le job qui communique la déclaration du ticket à l'outil tiers récupère le numéro du ticket nouvellement créé, et l'associe automatiquement
  • une requalification de l'événement :
    • cela changera l'état du check manuellement, et ce dernier gardera cet état jusqu'à la résolution de l'alarme
    • cela émettra un événement de type check, comme le superviseur
    • la seule différence est la présence d'un champ keep_state qui vaut true dans l'événement

Toutes ces actions permettent ainsi d'unifier une supervision hétérogène, et l'administrateur (technique) ne devra utiliser/maîtriser qu'un seul outil.

Sélecteur et widget météo : simplifier la supervision

Lorsque l'on supervise une grosse infrastructure, les informations remontées via les checks deviennent tout de suite beaucoup plus conséquentes. C'est pourquoi nous avons mis en place la possibilité d'agréger ces checks afin d'avoir une visibilité plus simple sur l'infra.

Cette agrégation se fait à l'aide des sélecteurs :

  • on créé un filtre d'événements
  • on applique un algorithme à l'état de chaque check qui matche le filtre (actuellement seul l'algo Worst State est disponible)
  • on produit un événement de type selector qui contient :
    • l'état agrégé
    • le champ output qui est le rendu du template spécifié dans la configuration du sélecteur
  • si le sélecteur est configuré pour, on déclenche le calcul des SLA :
    • sur une période de temps (spécifiée dans la configuration du sélecteur)
    • on calcule le pourcentage de temps passé sur chaque état possible
    • on produit une métrique pour chacune de ces métriques, ainsi qu'un événement de type sla
    • l'état remonté par l'événement correspond aux seuils de SLA configurés dans le sélecteur

Le résultat est finalement affichable avec un widget weather :

NB: Le sélecteur peut afficher également des checks unitairement

On peut ainsi noter les couleurs suivantes :

  • vert : l'état du sélecteur est INFO
  • jaune : l'état du sélecteur est MINOR
  • orange : l'état du sélecteur est MAJOR
  • rouge : l'état du sélecteur est CRITICAL
  • violet : toutes les alarmes du sélecteur ont été acquittée
  • la couleur du widget est celle du pire état des sélecteurs positionnés dans celui ci

Un clic sur le sélecteur dans le widget nous redirigera sur le Bac à événements, filtré avec le filtre du sélecteur.

Monitoring et séries

Chaque connecteur, moteur, et sélecteur produisent des données de performances :

  • temps d'exécution d'un check
  • usage CPU/RAM/Disque
  • temps moyen passé sur un événement
  • nombre moyen d'événements par seconde
  • donnée de SLA

Tout cela est remonté dans Canopsis dans un événement via le champ perf_data_array :

{ // info de l'événement classique "perf_data_array": [ { "metric": "nom_de_ma_metrique", "value": 42.1337, "type": "GAUGE", // GAUGE, COUNTER, ABSOLUTE ou DERIVE // champs optionnels "unit": "...", "min": 0, "max": 1337.42, "warn": 1000, "crit": 1300 } ] }

Ces données vont être historisée dans Canopsis. On peut donc noter 4 types de métriques :

  • GAUGE : on historise la valeur telle quelle
  • COUNTER : lorsque l'on récupère la valeur, on fait l'addition des valeurs historisées
  • ABSOLUTE : on historise la valeur absolue
  • DERIVE : il s'agit de la valeur dérivée par rapport au temps

Une métrique est ensuite identifiée par :

  • le composant de l'événement
  • la ressource de l'événement
  • le nom de la métrique dans le tableau de perfdata

Le tout peut être affiché dans un chart :

On est ainsi en mesure de sélectionner un ensemble de métrique avec un filtre basé sur des expressions régulières :

  • co:.*\.myhost re:cpu-.* me:system me:user me:wait

Qui se traduit en filtre MongoDB :

{ '$and': [ {'component': {'$regex': '.*\.myhost'}}, {'resource': {'$regex': 'cpu.*'}}, { '$or': [ {'name': {'$regex': 'system'}}, {'name': {'$regex': 'user'}}, {'name': {'$regex': 'wait'}} ] } ] }

Une fois les identifiants de métriques récupérés, on peut aller demander les points stockés en base, dans une fenêtre de temps bien définie.

Une série est donc munie :

  • d'un filtre de métrique
  • d'une période d'agrégation avec un opérateur d'agrégation (le manager de perfdata nous retournera les données agrégées)
  • d'une période de consolidation
  • d'une formule de consolidation

Ici la partie consolidation sert à consolider les différents points agrégés en un seul, afin de produire une nouvelle métrique.

La formule se construit de la manière suivante :

  • on a des opérateurs qui prennent en paramètre un filtre de métrique qui sera appliqué sur l'ensemble de métriques déjà sélectionnées
  • ces opérateurs retournent un point consolidé
  • on peut les utiliser dans une expression mathématique classique

Par exemple, SUM("me:.*") / COUNT("me:.*"), permet de réaliser une moyenne.

Les tâches ordonnancées et les notifications

Parmi les moteurs de Canopsis, certains sont dédiés à une fonction précise : exécuter une tâche.

Il y a donc un moteur scheduler qui, régulièrement, va chercher à exécuter des jobs configurés selon une règle de récurrence.
En fonction du type de job, ce dernier sera redirigé au moteur correspondant, que l'on appellera un taskhandler.

Cela permet de construire un équivalent de crontab au sein de Canopsis.

Ces taskhandlers ne servent pas uniquement à l'exécution de tâches ordonnancées, ils peuvent être utilisés en tant que notification :

  • une règle du moteur event_filter peut déclencher l'exécution d'un job si l'événement reçu matche le filtre de la règle
  • par exemple, à la réception d'un événement declareticket, on peut lancer l'exécution d'un job réalisant une requête d'insertion de ticket à un outil tiers
Conclusion

Grâce à tout ces éléments, Canopsis est en mesure de répondre à de nombreux besoins, allant de la supervision simple, à l'analyse poussée de données afin de générer des rapports sur une infrastructure (ou autre).

Notre objectif premier est la modularité du projet, afin de pouvoir fournir une solution sur mesure et de ne pas transformer l'outil en énorme usine à gaz. Pour résumer, on a répondu à cette problématique avec :

  • le découpage du backend en projets Python embarquant : un manager, éventuellement un moteur et un webservice
  • le découpage du frontend en briques embarquant : des composants, des renderers, des éditeurs, des mixins, des widgets
  • la schématisation des données et à l'avenir des actions possibles sur cette dernière (transformation, schématisation de l'API des managers, …)
  • le développement d'API générique permettant le changement de technologies sans modification du code

Beaucoup de choses ont été faites, et beaucoup de travail reste à faire, notamment :

  • la finalisation des rôles Ansible
  • l'intégration d'une notion de graphe pour les entités qui sont le centre de toutes les données stockées par Canopsis, afin de rendre le système complètement réflexif
  • une séparation totale du backend et du frontend, permettant d'utiliser l'un sans l'autre
  • génération de code à partir des schémas

Bref, Canopsis est en constante évolution, et touche à de nombreuses problématiques toutes plus intéressantes les unes que les autres.

Télécharger ce contenu au format Epub

Lire les commentaires

Agenda du Libre pour la semaine 6 de l'année 2016

7 février, 2016 - 01:18

Calendrier web, regroupant des évènements liés au Libre (logiciel, salon, atelier, install party, conférence) en France, annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 28 événements est en seconde partie de dépêche.

Sommaire Agenda du Libre pour la semaine 6 de l'année 2016 [Kunheim] Formation Linux - Le lundi 8 février 2016 de 18h00 à 22h00.

Tous les lundis à partir de 18h00 jusqu'à 22h00 venez découvrir ou vous former sur Linux et les logiciels libres.
Ces séances de formation ont lieu à la salle "Kegreiss" au 56 rue principale - Kuhneim - face à la mairie - cette salle est accessible aux personnes à mobilité réduite.
Nous vous attendons nombreux. Le Team Linux

[Paris] Atelier OpenData - Le lundi 8 février 2016 de 19h00 à 22h00.

L'atelier « Opendata : les enjeux des données ouvertes » est organisé par Ritimo et animé par Regards Citoyens.
Il est à destination du monde associatif (venir avec son portable). L'entrée est libre et l'inscription obligatoire.
Extrait de la présentation :

[Teyran] Notions PC - Le mardi 9 février 2016 de 09h00 à 10h00.

Réaliser une carte d’invitation avec le traitement de texte LibreOffice Writer
Writer est le composant de traitement de texte de LibreOffice. En plus des fonctionnalités habituelles d’un traitement de texte (correcteur orthographique, dictionnaire des synonymes et de coupure de mots, autocorrection, rechercher et remplacer, génération automatique de table des matières et d’index, mailing et autres) Writer fournit des modèles et styles, des méthodes de mise en page incluant les cadres, les colonnes et les tableaux, incorporer ou lie des images, des feuilles de calcul et d’autres objets, il a des outils de dessins natifs, possède un suivi de modification, exporte en PDF, incluant les repères de texte…
La participation aux ateliers nécessite :

[Castelnau-le-Lez] Section GNU/Linux - Le mardi 9 février 2016 de 10h00 à 12h00.

Rendez-vous hebdomadaire, tous les mardis, salle 38 de la mjc (hors vacances scolaires).
L’équipe de Montpel’libre vous propose une permanence de dépannages pour vous aider à vous familiariser avec votre système GNU/Linux au quotidien.
Le contenu de l’atelier s’adapte aux problèmes des personnes présentes et permet ainsi d’adapter l’acquisition de nouvelles compétences au rythme de chacun.

[Castelnau-le-Lez] Atelier de développement et programmation - Le mardi 9 février 2016 de 10h00 à 12h00.

Rendez-vous hebdomadaire, tous les mardis, salle 40 de la mjc (fermé pendant les vacances).
Cet atelier de développement est essentiellement axé sur les langages du Web : html, css (même si ce ne sont pas des langages à proprement parler) javascript et PHP, possibilité aussi d’utiliser Ajax, Jquery, Sqlite et MySql.
Notre équipe vous attend pour répondre à vos questions et satisfaire votre curiosité.

[Brignoles] Atelier Libre - Le mardi 9 février 2016 de 18h30 à 21h30.

Les membres de l'association GULLIVAR (Groupe d'Utilisateurs de Logiciels Libres de l'Intérieur du Var) vous invitent à une soirée atelier / présentation logiciel libre qui aura lieu le 9 février 2016, dans la salle des Saint Anges, chemin de San Sumian à Brignoles à partir de 18h30.
À 19h30, l'atelier / présentation.
Cette soirée est ouverte à tous, adhérents et sympathisants.

[Bordeaux] Atelier CLI - Le mardi 9 février 2016 de 19h00 à 21h00.

Damien Goutte-Gattat, post-doctorant à l'Institut Européen de Chimie et Biologie, présentera GnuPG (GNU Privacy Guard) pour les utilisateurs avancés.
Déjà habitué avec ses articles, tel que « De la gestion des clefs OpenPGP », postés dans son journal sur linuxfr.org, cet atelier sera certainement très instructif. On pourra, en autre, créer sa clé GPG et la partager :)
L'atelier sera suivi d'un apéritif permettant aux participants de se rencontrer et de poursuivre la discussion.

[Paris] Tuppervim #43 - Le mardi 9 février 2016 de 20h00 à 22h00.

Le tuppervim est un évènement mensuel organisé dans les locaux de Mozilla.
Il a lieu un mardi du mois (généralement le premier).
Le texte suivant a été honteusement copié du site http://tuppervim.org

[Teyran] Notions PC - Le mercredi 10 février 2016 de 09h30 à 10h30.

Ajouter de la profondeur de champ à une photographie avec Gimp
Gimp offre de nombreuses fonctionnalités. Il peut être utilisé comme un simple programme de dessin, comme un programme de retouche photo, comme un système en ligne de traitement par lot, comme un générateur d’image pour la production en masse, pour convertir un format d’image en un autre. GIMP est extensible. On peut lui ajouter de nombreux « Greffons » (plug-ins). Une interface de scripts bien développée permet de créer des procédures, les scripts, regroupant plusieurs opérations.
La participation aux ateliers nécessite :

[Nantes] Quadr'apéro - Le mercredi 10 février 2016 de 19h00 à 23h00.

Venez discuter des libertés et d'Internet au quadr'apéro mensuel.
Venez nombreux.
Entrée Libre. Tout Public.

[Paris] Atelier design : les couleurs - Le mercredi 10 février 2016 de 19h00 à 21h00.

Atelier Do It Yourself Design : 16,8 Millions de couleurs, et moi et moi!
Dans la série des atelier Do it yourself, l’association Silex Labs vous propose un nouvel atelier pour découvrir l’importance des couleurs dans les projets numériques. Cet atelier sera animé par Pol Goasdoué designer professionnel spécialiste de l’UX UI Président de l’entreprise UFO et co-fondateur du projet Silex.
Au programme de cet atelier

[Paris] Apéro des nouveaux mozilliens - Le mercredi 10 février 2016 de 19h00 à 21h00.

L'apéro des nouveaux aura lieu le 10 février à partir de 19h chez Mozilla (16 bis boulevard Montmartre, 75009 Paris).
Ça sera bien évidement l'occasion pour les nouveaux de rencontrer une partie de la communauté mozfr et pour tous de (re)découvrir comment il est possible de participer. Plus largement, ça serait chouette qu'on profite de l'occasion pour se dire sur quoi on bosse et sur quoi on aimerai bosser. Ça permet de mieux savoir qui est intéressé par quoi et de faciliter la participation de nouvelles personnes. Tout cela se faisant bien sûr  de manière informelle et dans la bonne humeur.
Afin de gérer l'intendance, veuillez-vous inscrire sur le pad:https://public.etherpad-mozilla.org/p/aperoNouveaux

[Proposition en ligne] Appel à communications AgoraCMS 2016 - Du jeudi 11 février 2016 à 00h00 au vendredi 12 février 2016 à 00h00.

La 3ème édition d'AgoraCMS, premier événement européen dédié aux CMS se tient à Paris le 1er avril prochain.
L'appel à communications pour les conférences vient d'être lancé: http://agoracms.com/appel-a-communication.
Vous pouvez y proposer vos idées de conférences, de retours d'expérience, de vos projets.

[Mauguio] Infolibres - Le jeudi 11 février 2016 de 17h00 à 19h00.

Rendez-vous salle de formation informatique de la médiathèque.
L’équipe de Montpel’libre vous propose une permanence de dépannages pour vous aider à apprivoiser votre système GNU/Linux au quotidien. Le contenu de l’atelier s’adapte aux problèmes des personnes présentes.
Vous pourrez y aborder entre autre :

[Paris] Mapathon Missing Maps - Le jeudi 11 février 2016 de 19h00 à 22h00.

Venez découvrir comment contribuer à OpenStreetMap, le "Wikipedia de la carte", durant un « mapathon » !
(un événement convivial où l'on se retrouve pour cartographier, échanger et apprendre à utiliser les outils permettant de contribuer à OSM).
Cet événement s'inscrit dans le cadre de l'initiative globale Missing Maps, projet humanitaire qui vise à cartographier en amont les parties du mondes vulnérables aux catastrophes naturelles, crises sanitaires, environnementales, aux conflits et à la pauvreté.

[Lyon] Jeudi du Graphisme - Le jeudi 11 février 2016 de 19h00 à 21h00.

L'Association Lyonnaise pour le Développement de l'Informatique Libre organise un atelier découverte du logiciel : Darktable : Corrections et profils d’effet qui est animé par les étudiants de la licence CoLibre.
Darktable est un logiciel de développement et retouche de photo. L’application pour les photographes passionnés. Cette année, nous appliquerons à voir quelques techniques de retouche simple et utile et surtout comment créer des profils d’effets qui seront la signature de votre touche personnelle.
Entrée Libre et gratuite

[Paris] Soirée de Contribution au Libre - Le jeudi 11 février 2016 de 19h30 à 23h00.

Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.
Nous nous réunissons donc tous les jeudis soirs dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies)).
Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

[Montpellier] Formation sécurité informatique et cryptographie - Le vendredi 12 février 2016 de 09h00 à 13h00.

Montpel’libre a le plaisir de vous proposer un nouveau cycle de formation, cryptographie et sécurité informatique.
Merci d’avoir choisi de participer aux ateliers « Sécurité Informatique et Cryptographie » organisés par Le Club de la Presse et Montpel’libre. Les trois ateliers auront lieu les vendredis 5, 12 et 19 février 2016 de 9h00 à 13h00 à l’Atelier des Pigistes du Club de la Presse de Montpellier.
Formation Crypto, séance de préparation, premier module :

[Paris] Locasprint MozFR n°4 - Du vendredi 12 février 2016 à 14h00 au dimanche 14 février 2016 à 20h00.

La communauté Mozilla francophone organise son 4e évènement autour de la traduction. La communauté Mozilla de bénévoles francophones est à l’origine de l’ensemble du contenu en français publié par Mozilla (logiciels, sites web, documentation, pages d’assistance, etc.)
Cet évènement est ouvert à toute personne qui souhaite nous aider à produire des traductions françaises de qualité. Vous avez juste besoin de venir avec un ordinateur et de la motivation.
Ce week-end de travail est l’occasion d’accueillir de nouveaux contributeurs, de leur expliquer notre façon de travailler, nos outils, nos bonnes pratiques…

[Montpellier] Permanence Les logiciels libres - Le vendredi 12 février 2016 de 17h00 à 19h00.

Le Faubourg Marché, qu’est-ce que c’est ?
Le Faubourg Marché est une permanence partagée qui permet aux associations d’accueillir ensemble, les publics de ces associations une fois par semaine, le vendredi entre 17h00 et 19h00 (ou au delà sous réserve d’accord préalable), au 19, rue du Faubourg de Nîmes, 34000 Montpellier.
Si vous avez un peu de temps le vendredi soir, voici une occupation qui me semble très intéressante et si vous êtes intéressés par la promotion des logiciels libres, des biens communs, de l’accessibilité, de l’économie sociale et solidaire, de l’innovation sociale et numérique, de l’éducation populaire, ou encore du développement durable.

[Villeneuve d'Ascq] Libre à Vous - Le samedi 13 février 2016 de 09h00 à 12h00.

Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres ?
Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.
C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

[Castelnau-le-Lez] Café Numérique GNU/Linux & Logiciels Libres - Le samedi 13 février 2016 de 09h00 à 11h00.

Samedi 13 février 2016 de 9h00 à 11h00 MJC Centre André Malraux 10, avenue de la Moutte, 34170 Castelnau-le-Lez
Bus Ligne 35 arrêt Collège Frédéric Bazille Tramway ligne 2 arrêt La Galine
GPS : Latitude : 43.633946 | Longitude : 3.905794

[Teyran] Notions PC - Le samedi 13 février 2016 de 09h30 à 10h30.

Enregistrer, importer, manipuler des fichiers sonores avec Audacity
Audacity est un logiciel libre4 pour la manipulation de données audio numériques. Audacity permet d’enregistrer du son numérique par le biais des entrées ligne/micro/cd des cartes sons. Il permet d’éditer (copier, coller, sectionner…) les sons sur plusieurs pistes, et il est accompagné de divers filtres et effets : pitch, tempo, réduction de bruit, égaliseur, filtres de Fourier, augmentation de fréquences précises, compression, amplification, normalisation, écho, phaser, wahwah, inversion…
La participation aux ateliers nécessite :

[Toulouse] Atelier Blender pour tous - Le samedi 13 février 2016 de 10h00 à 18h00.

La communauté toulousaine des utilisateurs de Blender est l'une des plus actives de France.
Elle se retrouve régulièrement pour organiser des ateliers, des repas, des soirées.
C'est donc dans ce cadre que le Blender User Group toulousain organise, en coopération avec Toulibre, environ un samedi par mois, de 10h à 18h dans les locaux de l'espace Ékito, 15 rue Gabriel Péri à Toulouse.

[Saint-Denis] Assemblée générale de l'April - Du samedi 13 février 2016 à 13h00 au dimanche 14 février 2016 à 19h00.

L'assemblée générale de l'April aura lieu le samedi 13 février 2016 de 14h à 18h (accueil à partir de 13h00) à l'université Paris 8 à Saint-Denis (bien que l'AG se tienne en 2016, elle concerne le bilan de l'année 2015 mais bien sûr les perspectives 2016 seront abordées).
Il s'agit d'un des événements importants de la vie de l'association, l'occasion de voter les rapports moral et financier, faire un point sur l'année qui vient de s'écouler, de rencontrer les autres adhérents et d'élire le conseil d'administration.
L'assemblée générale est l'occasion d'organiser un week-end de réunion des membres. Le dimanche sera consacré à des ateliers en petits groupes ou discussions en plénière. Ce week-end est en cours d'organisation, plus de détails bientôt. Cette partie atelier est ouverte à tout le monde et aura lieu à la Fondation pour le Progrès de l'Homme à Paris. Une soirée festive est prévue le samedi soir et des ateliers sont prévus le dimanche. Le lieu pour la soirée n'est pas encore fixé.

[Ramonville Saint Agne] Atelier web: les squelettes sous SPIP - Le samedi 13 février 2016 de 14h00 à 18h00.

Deux nouvelles animations organisées très prochainement par le Projet Internet et Citoyenneté à la Maison des Associations de Ramonville. Ces deux animations sont complémentaires: c'est une bonne idée de participer aux deux, mais ce n'est pas obligatoire.
1/ SAMEDI 30 JANVIER 2016: Personnaliser son site Web avec les CSS: Initiation aux CSS. À partir de la version distribuée de SPIP, personnaliser son site en modifiant les fichiers CSS.
2/ SAMEDI 13 FEVRIER 2016: Initiation à l’écriture/modification des squelettes qui conditionnent les fonctionnalités présentes dans les pages d’un site sous SPIP. Modifier le squelette des articles, rubriques, etc. pour changer l’aspect et les fonctionnalités présentes dans les pages du site.

[Saint-Aunès] Permanence Emmabuntüs et Logiciels Libres - Le samedi 13 février 2016 de 14h00 à 18h00.

Samedi 13 févier 2016 de 14h00 à 18h00 Communauté Emmaüs Montpellier-Saint-Aunès La Vieille Cadoule 34130 Saint-Aunès
GPS Latitude : 43.649363 | Longitude : 3.991591
Rendez-vous mensuel, le deuxième samedi. Pour les animateurs, réservez les repas et le covoiturage le jeudi au plus tard.

[Marseille] Atelier « Découverte des Logiciels Libres Firefox » - Le samedi 13 février 2016 de 14h30 à 18h00.

L’association CercLL vous invite à l’ Atelier du Samedi Libre qui se déroule le samedi 13 février 2016 de 14h30 à 18h00, à la Fabulerie 4 rue de la Bibliothèque 13001 Marseille.
Ces ateliers se déroulent, en général, sur une séquence hebdomadaire, de 2 à 3 séances de travail et sur un thème déterminé.
Comme le mot atelier le laisse présumer, dans ce cadre, nous proposons une approche pratique des outils libres.

Télécharger ce contenu au format Epub

Lire les commentaires

Mais où est donc la révolution des imprimantes 3D ?

6 février, 2016 - 13:54

Depuis quelques temps déjà on nous annonce la révolution des imprimantes 3D. Mais, dans notre vie quotidienne, toujours rien ! Mais où est donc cette révolution ?

Ceux qui possèdent une imprimante 3D ont une approche un peu différente de la consommation. Par exemple, quelqu'un de chez Ckab s'est fabriquée un autre bouton de pantalon, certains ont facilement réparé leur chasse d'eau ou un autre objet en plastique. La plupart des objets deviennent réparables :-)

Pour les professionnels aussi c'est une approche différente, par exemple en cuisine, remplacer le plastique par une pâte, comme la pâte à pain ou une pâte de chocolat.

Et cette révolution est d'autant plus importante qu'elle est animée par l'esprit du partage et de l'open hardware.

Sommaire La révolution en marche

De plus en plus de particuliers s'offrent une imprimante 3D (~1000€), de plus en plus d'entreprises se créent sur ce secteur, les passionnés s'organisent en fablabs et des objets libres peuvent être dupliqués :

Il y a aussi la possibilité de faire du prototypage rapide pour les projets industriels, beaucoup plus facilement et rapidement. Par exemple, le projet de caméra cinéma ouverte Apertus AXIOM a pu créer des prototypes de son futur boîtier en taille réelle.
Cela ouvre la création hardware, même à objectif final professionnel et industriel, à bien plus de gens.

Bientôt, au lieu de jeter un appareil électroménager, nous pourrons fabriquer la pièce défectueuse… À condition que les plans des objets soient librement disponibles. (Oui c'est vrai : combien de fois, un petit élément en plastique se casse, comme dans sa chasse d'eau, et plus rien ne fonctionne correctement).

Et c'est bien cet esprit de matériel ouvert qui permet d'éviter que des industriels monopolisent l'innovation en brevetant les systèmes. Ainsi le projet RepRap partage sous licence libre des imprimantes 3D qui sont capables de s'auto-dupliquer, excepté les tiges métalliques et circuits électroniques (mais cela viendra peut-être).

En pas libre, des sociétés proposent d'imprimer des objets proposés par des créateurs très geeks matheux comme des fractales 3D, des polygones réguliers, et autres pavages hexagonaux projetés à la bougie … Il devient aussi possibles d'imprimer des figurines pour les geeks de types board game … ouvrant la voix à un modèle économique pour le jeu de plateau libre ?

Retour aux sources

Les RepRaps sont nées de l'idée d'un professeur anglais qui a décidé que cette impression 3D, inventée même avant le noyau Linux, devait l'être pour tous. L'engouement des passionnés a fait le reste et, devant ce succès, sont nées des machines grand public prêtes à l'emploi. Mais ce sont bien les RepRaps qui ont permis deux choses :

  • Rassembler des citoyens pour défendre la liberté de créer des objets
  • Définir les standards techniques

Dans ce domaine, le monde du Libre joue, avec des leviers considérables, de tous ces atouts (rapidité et flexibilité des modèles, contributions ultra-actives, recherches pointues et audacieuses !), laissant souvent derrière les industriels les plus motivés. Et c'est tant mieux car cela a déjà permis d'imposer le consommable sous forme de bobine et non pas en cartouches munies de puces ! Rien que ça, c'est une titanesque victoire !

États des lieux entre brevets et communautés libres

D'un côté nous avons de plus en plus d'entreprises qui se créent pour répondre aux besoins d'autres entreprises et institutions de créer des objets décoratifs, intelligents et connectés. C'est le cas de la jeune start-up CKAB qui a bien voulu répondre à nos questions.

Il y a aussi les fabricants d'imprimantes 3D qui sont tentés de déposer des brevets pour affaiblir les marges d'innovation des concurrents, puis monopoliser le marché pour pratiquer ses propres tarifs, et ainsi pérenniser/augmenter leurs revenus. Tous les industriels n'ont pas ce comportement, mais comme d'autres le pratiquent (et que c'est légal), pourquoi s'en priver ?

Parmi les concurrents, de l'autre côté, nous avons les particuliers qui s'émancipent et partagent librement leur passion. Ce sont des communautés rassemblées le plus souvent en fablabs. Mais aussi, des particuliers qui s'équipent chez eux tels des artisans.

Tous ne viennent pas du monde du logiciel libre (pour ne pas dire presque pas). Mais tous ont goûté la satisfaction de l'entraide, du partage des sources et des bienfaits de l'open hardware.

Entretien avec Romain Pouzol, directeur des opérations de la société CKAB

Cette jeune start-up CKAB est revendeur officiel de la marque d'imprimantes 3D Makerbot et propose également la conception et la fabrication d'objets plus ou moins complexes.

D'où est venue l'idée de créer CKAB ?

Lorsque le matériel open-source (ou libre, attention #troll_inside) est apparu, porté par l’émergence du financement participatif, non seulement on a relativement1 décloisonné certaines technologies mais en plus et surtout, on a ouvert un univers d’usages collaboratifs, circulaires, inédits et virtuellement infinis.
En d’autres termes, l’OSHW nous a donné le pouvoir de dématérialiser, de transformer et de re-matérialiser notre environnement physique.

Dès lors, nous avons commencé à explorer cet univers des possibles, d’abord par la voie de la petite électronique open-source par le biais de notre e-shop Hackable-Devices (transféré et intégré depuis sur CKAB.io) puis par la voie des imprimantes 3D de bureau.
Pour être tout à fait clair, ce n’est pas la Technologie en tant que telle qui nous intéresse au premier plan, ce sont les usages que l’on peut en faire et sur ce point, je ne vois pas comment le monde privatif pourrait rivaliser, à terme, avec le monde ouvert.

À titre plus personnel, ce sont plus particulièrement les répercussions au plan politique — au sens strict du terme — qui m’intéressent. Je vois en l’impression 3D la même lame de fond « d’empowerment » des masses que celle que l’on a connue avec les médias sociaux, à la différence près que cette fois, on fait disparaître toute frontière entre environnement matériel et immatériel. Ma conviction est que si les ténors du secteur n’embrassent pas dès maintenant le phénomène de la fabrication numérique, les consommateurs le feront pour eux et là, oui, les industriels souffriront.

CKAB se définit aujourd’hui comme « l’agence de la fabrication numérique et des objets intelligents » et il suffit de nous rendre visite (1 place Saint-Gervais – 75004 Paris) pour se rendre compte que, si nous sommes une entreprise commerciale et non un FabLab, notre environnement ressemble plus au laboratoire du professeur Tournesol qu’à de cliniques bureaux d’import/export d’électronique.

Quelle est la première activité ou l'activité la plus lucrative ?

Au début de l’activité, les ventes d’imprimantes 3D portaient la société. Sauf erreur de ma part, CKAB a été, avec notre partenaire belge de l’époque, l’importateur historique de MakerBot en Europe. On a donc la petite fierté de compter parmi les rares à avoir mis les mains sur les cinq générations de machine… et à les avoir bien modifiées.
Aussi fou que cela puisse paraître, je crois que nous sommes les seuls à avoir pris la peine de, par exemple, traduire l’interface de la machine en français. Ce n’était clairement pas un immense exploit mais le plus cocasse est qu’aucun de nos confrères ne semble s’être donné la peine de reprendre notre travail pour un portage en allemand, espagnol, etc.
C’est assez révélateur de l’état d’esprit du marché. Cela était prévisible mais reste dommage.

Aujourd’hui, ce sont nos activités de conseil et d’évènementiel qui sont les plus importantes. Non pas que nous ne vendons plus de machines mais plutôt que l’acquisition du matériel intervient en fin de parcours.
Nous avons dorénavant affaire au responsable du bureau d’étude, au CTO voire à des achats stratégiques décidés au niveau de la direction générale. Dans le secteur public, nous sommes passés d’achats isolés de tel ou tel collège/lycée à des investissements portés par des Régions, des académies ou encore des Ministères.

Les équipements sont donc plus réfléchis mais ne nous y trompons pas, les entreprises restent très souvent perdues dans la jungle.
C’est sur ce point que nous intervenons : établir la (non-)pertinence directe de ces technologies pour l’entreprise, les accompagner dans une phase exploratoire en prototypant produit ou service, et enfin, si nécessaire, les équiper avec le matériel adéquat et former les collaborateurs.
CKAB représente aujourd’hui une cellule de veille technologique qui performe parce qu’elle dispose d’un savoir et d’un savoir-faire tant du côté software que du côté hardware.

Pour autant, si l’on a travaillé dur pour gagner la confiance de groupes tels que Safran, Air Liquide, Chanel, Auchan, Renault (…), nous ne voulons surtout pas perdre les relations que nous entretenons avec les PME et les artisans car ce sont aussi voire surtout ces entreprises qui, de par leur souplesse inhérente à leur taille, sont à la source de l’innovation dans notre cher pays.
Et quitte à paraître un peu prétentieux, je pense qu’assez rares sont les entreprises qui peuvent se permettre ce grand écart…surtout quand on est une équipe qui vient tout juste de passer à 3 personnes :-)

À quel point le secteur est-il en croissance ?

La recherche est très active, en particulier dans le domaine de la santé. L’avenir (15~25 ans) nous réserve de très belles choses.
On parle d’impressions de tissus vivants, d’organes, de prothèses et si l’on a un peu d’imagination et que l’on associe la bio-impression 3D aux nanotechnologies, on verse rapidement dans l’humain augmenté, le trans-humanisme, la fameuse singularité.
À ce niveau expérimental, l’open-source fonctionne à plein régime et m’est avis que si 2016 verra de nombreux FabLabs et assimilés fermer, on verra également un essor de lieux tiers orientés biologie tels que le bio-hackerspace « La Paillasse » à Paris.

La recherche un peu plus appliquée est également en ébullition depuis quelques années. Il reste de nombreux obstacles à lever et tous ne sont pas de nature technique mais, globalement, les efforts sont portés sur le passage du prototypage à celui de la production d’objet fini ; qu’il s’agisse d’outillage rapide ou de sous-ensembles présents dans des biens de consommation.

Au niveau des particuliers, certes les machines s’améliorent et peuvent se simplifier — ce qui est souvent synonyme d’un enfermement dans une prison dorée avec une perte de contrôle conséquente sur le matériel — mais il n’y a pas de révolution. On reste par exemple toujours ou presque sur du dépôt de filament fondu donc une seule matière et une seule couleur.
À ce niveau, l’Open-Source est moteur avec tout ce que cela sous-entend en termes de collaboration. Il suffit d’examiner l’arbre généalogique du mouvement RepRap pour s’en rendre compte : plus de 400 projets et encore, cela ne couvre que 2006-2012 !

Et je ne parle même pas des machines qui tirent parti du firmware open-source Marlin mais qui ne sont pas des RepRap pour autant car pas OSHW.

À côté de cela, je fais partie des personnes qui ne pensent pas que chaque famille Michu aura une imprimante 3D chez soi à court voire à moyen terme.
En effet, même si l’on pose l’hypothèse que le matériel sera accessible financièrement et techniquement parlant, même si l’on admet que les matériaux seront disponibles pour tous, reste la question de la CAO.
Dessiner un objet véritablement utile en 3D est quelque peu plus complexe que d’ouvrir son traitement de texte…
Certes des solutions logicielles apparaissent mais ce n’est pas la panacée.
En ce sens, les machines qui clament haut et fort un comportement plug’n play sont soit de quasi-jouets soit sont techniquement capables mais tellement castrées par un logiciel privatif que leur usage est des plus restreints.
Au niveau de cette dernière strate, on voit donc beaucoup d’agitation mais beaucoup moins de choses réellement innovantes, fonctionnelles et pérennes ; ce qui est normal car elles appellent un marché qui ne répond pas.

De là à dire que l’impression 3D n’impactera jamais le grand public, il y a un pas que je me garde bien de franchir. Nous avons quelques idées mais ça, c’est une autre question… ;-)

Y a-t-il de la place pour d'autres entreprises dans ce secteur ?

Le marché de la distribution de matériel est devenu très concurrentiel, malheureusement parce que certains ont évidemment fait le choix de la chasse au dernier euro au détriment de la qualité du matériel et du service, ce qui a tiré une bonne partie du marché vers le bas.
Démarrer aujourd’hui une activité de revente de machines me semble donc compliqué.

Par contre, il y a encore de la place dans le secteur de la conception de machines même si partir la fleur au bout du fusil avec un produit minimum viable (MVP) financé par crowdfunding est aujourd’hui relativement illusoire.

Quelle est la philosophie de Makerbot ?

Avant son rachat par Stratasys (2e acteur mondial) en 2012 pour 400 M$, Makerbot travaillait pour et avec les Makers. Grosso-modo, on peut dire que si l’on cherchait une machine de bureau qui fonctionne bien pour en faire un usage professionnel, il n’y avait que MakerBot qui comptait.

Depuis le rachat, il y a eu de nombreux changements de stratégie et de direction générale, la ligne directrice est plus floue. Trop souvent les produits n’ont pas été en phase avec le marketing.
En guise d’exemple, CKAB ne vend quasiment pas d’imprimante 3D MakerBot de 5e génération, nous préférons l’avant-dernière génération : moins chère, plus silencieuse, plus rapide, plus évolutive, plus performante.
Ces machines de 4e génération sont par ailleurs toujours open-source au niveau du firmware et nous les avons bien transformées au niveau matériel ce qui fait que même 3 ans après leur sortie, les Replicator2 améliorées par CKAB comptent toujours parmi les meilleures machines du marché.

Je ne vais pas m’attarder sur les dessous de l’affaire, je vous conseille de lire ces quelques articles :

Quelle est la part de marché de Makerbot ?

Je ne saurais dire précisément. Je pense qu’ils sont toujours les premiers au plan mondial même si la 5e génération de machines leur a fait du mal. Quoi qu’il en soit, ils ont les ressources pour atteindre leurs objectifs.

Quelles relations avec l'open hardware, les licences libres, les forums d'entraide, les fablabs ?

Si l’on parle de MakerBot, plus aucune à ma connaissance depuis le rachat par Stratasys.

Si l’on parle de CKAB, nous ne sommes pas des sectaires du Libre ou du propriétaire mais tant que faire se peut, on essaye de travailler avec des composants ouverts, qu’il s’agisse de logiciel ou de matériel.
Quand on développe des prototypes d’objets intelligents pour nos clients, il ne s’agit pas forcément de payer moins cher telle ou telle brique logicielle ou matérielle mais plutôt de bénéficier de documentation, de souplesse d’utilisation, de partage (…) bref d’efficacité.

Quant à donner en retour, on privilégie les actions concrètes sur le terrain plutôt qu’en ligne : atelier de soudure, prix doux pour fablabs, etc.

Que conseiller aux lecteur de LinuxFr.org pour s'y mettre ?

Tout dépend de ce que vous cherchez. Si vous souhaitez vous amuser à bidouiller – au sens noble du terme – une imprimante 3D, alors on pourra vous conseiller mais CKAB ne sera probablement pas votre interlocuteur commercial.
Par contre, si vous préférez avoir un outil stable bien qu’ouvert donc évolutif et vous concentrer sur les objets qui sortiront de votre machine, alors on sera probablement beaucoup plus en phase.

En ce qui concerne l’électronique, nous avons quelques joyeusetés en boutique mais nous ne cherchons pas à concurrencer selectronics ou sparkfun. Nous avons des compétences de sourcing, de dev soft et hard donc on peut accompagner pas mal de projets.

En tout état de cause, je recommanderais une bonne dose de patience enrobée de logique, quelques épices de passion voire de folie, le tout baignant dans un nuage d’imagination.

N’hésitez pas à nous rendre visite, sur rendez-vous :

  • 1 place Saint-Gervais – 75004 Paris, chez les Compagnons du Devoir,
  • Métro Pont-Marie ou Hôtel de ville.
  • Tel : 01 85 09 96 42
  • Courriel : contact@ckab.io
Faire ses premiers pas, la communauté, les fablabs Avantages et inconvénients de l'impression 3D Technologies actuelles

Les imprimantes 3D sont utilisées depuis plusieurs décennies pour la réalisation de prototypes. En effet, de manière générale, une pièce mécanique est d'abord conçue en CAO, prototypée, puis modifiée pour pouvoir la produire grâce aux méthodes traditionnelles (extrusion, moulage, etc.).

Aujourd'hui, que ce soit par stéréolithographie ou SLA, frittage sélectif par laser ou SLS, ou tout autre procédé dit additifs, voici les avantages :

  • possibilité de créer des pièces infaisables autrement (sphères internes, porosité pré-calculée, etc.)
  • rapidité relative pour la création de pièces à petit tirage ;
  • coûts en chute libre ;

Néanmoins, les impressions 3D ne sont pas très utilisées pour produire massivement pour plusieurs raisons :

  • lenteur pour produire des pièces à la chaîne ;
  • consommation énergétique très élevée ;
  • sécurité particulière (atmosphère sous Argon pour certains processus, toxicité des poudres nanométriques nécessaires en intrants, etc.).

En outre, toutes les technologies additives fabriquent des pièces non-isotropes, et mécaniquement peu viables. En effet, une pièce mécanique possède ainsi une résistance différente dans la direction perpendiculaire au plan d'impression par rapport au plan d’impression. L'état de surface est rugueux par définition, mais l'état interne est identique.

Or, il est connu des mécaniciens que tout angle vif est le siège le plus propice d'un développement d'une fracture de la pièce : il est possible d'utiliser cette propriété pour faire en sorte qu'une pièce casse à un endroit privilégié, et ainsi augmenter la sécurité. Mais avec une pièce contenant des irrégularités internes partout, il est impossible de faire confiance à cette pièce.

Demain

Ne nous voilons pas la face : tant qu'il faudra plusieurs heures ou jours pour fabriquer un produit, il est peu probable que cette technique s'impose pour la production de masse.

Néanmoins, on voit émerger de nouveaux produits tels ceux de l'entreprise Carbon3D qui permettent de produire des objets en polymères quelconques (même élastiques), de manière continue (aucune strate affaiblissante), et surtout de 25 à 100 fois plus rapidement (inspiré par Terminator 2).

Bref, les possibilités restent limitées par l'imagination humaine, mais j'attends personnellement que quelqu'un vienne avec une batterie où les anodes et cathodes sont des fractales tridimensionnelles pour faire un petit bond en densité d'énergie !

Conclusion : gare aux brevets !

Les années 90 ont vu le grand public s'équiper d'imprimantes 2D (encre sur papier). Un phénomène similaire peut aussi de se produire avec les imprimantes 3D, propulsant le grand public dans l'économie du partage. La révolution serait alors la possibilité de créer/partager pour un coût "abordable".

Comme pour le logiciel libre, le succès viendra des réseaux sociaux de partage des sources comme github. Mais comme le logiciel libre, la menace est celle des brevets qui risquent de verrouiller l'innovation.

C'est déjà le cas avec les codecs : nous en sommes toujours au JPEG standardisé en 1992 et le grand public ne profite pas librement des avancées majeures des Jpeg2000/…/HEVC car quelques pays puissants (USA, Japon) autorisent les brevets logiciels.

Et dans le monde des imprimantes 3D c'est pire, car les brevets matériels sont autorisés, même en Europe.

Donc ce sont les libertés des citoyens qui se jouent dans cette révolution. Est-ce que le grand public s'appropriera ces nouvelles technologies des imprimantes 3D et entrera dans l'économie du partage. Ou est-ce que nos gouvernements se laisseront séduire par les lobbies pour verrouiller le marché ?

Télécharger ce contenu au format Epub

Lire les commentaires