De la génération du code à la génération des applications (1/3)

Au début des année 2000, lorsque j'ai commencé la programmation, RAD vivait sa plus belle époque. Le développement se basait (pratiquement pour tous les langages) sur un ensemble d'outils d'édition visuelle et de composants réutilisables regroupés dans le même environnement. C'était l'époque des EDI (IDE). Durant cette époque, on a vu la naissance de Visual Studio, Delphi, C++ Builder, NetBeans, Eclipse et bien d'autres. Il y avait même des efforts sérieux pour des éditeurs visuels pour HTML.

Le principe est très simple : l'EDI traduit les actions visuelles vers un code. Si des ressources et des bibliothèques externes étaient nécessaires pour le projet alors il était nécessaire de les intégrer (télécharger et importer) au niveau de l'EDI; donner juste l'URL n'était pas suffisant. Dans cet article, je présente, pour illustrer ce point, le choix du LayoutManager d'une JFrame (sous Java) et les conséquence de la manipulation visuelle sur le code généré.

Cette approche a duré jusqu'au début des années 2010 lorsque le développement web a connu des grands changements. jQuery, NodeJS, AWS, NoSQL, les gestionnaires de dépendances et plein d'autres technologies peuvent être citées pour justifier ces changements. Les CMS tels que Drupal et Joomla ont perdus leur place pour ces nouvelles technologies et les outils RAD ont perdu aussi leur place pour un nouveau mode de développement. Un mode imposé par Node et son écosystème (aka npm) qui est considéré, aujourd'hui, comme le plus grand entre toutes les plateformes.

A mon avis, ce nouveau mode repose sur quelques principes :

• Utilisation massive des dépendances et une orientation totale vers la réutilisation,
• Utilisation des éditeurs simples avec des Copier/Coller : c'est très fréquent de trouver une bibliothèque dont la documentation (presque) entière est basée sur des exemples à Copier/Coller (Oracle Jet, présenté ici, à titre d'exemple),
• La génération des applications, non pas du code.

Personnellement, je me positionne contre cette nouvelle école. Je ne suis pas d'accord avec ces trois principes.

Premièrement, l'utilisation massive des dépendance en comptant exclusivement sur le gestionnaire des dépendances (maven, gradle, npm, gulp) a prouvé ses limites surtout lorsqu'un bon nombres des dépendances sur lesquels les projets sont fondés changement très fréquemment. L'exemple de lfetPad reste le cas le plus connu mais pas l'unique.

Deuxièmement, le Copier/Coller ne remplacera jamais l'écriture du code. Ne pas préparer une bonne documentation qui explique le principe de fonctionnement et l'architecture de la plateforme pour ensuite proposer des exemples du code a donné naissance à ce mode bizarre de développement. Si cela marche dans les cas ordinaires, les développeurs se trouvent coincés dès qu'une erreur imprévue dans l'exemple apparaît ce qui engendre par la suite une réduction considérable de la productivité.

source me.me

Finalement, la génération des applications (presque) entière vient pour remplacer la génération du code. En effet, la norme actuelle repose sur l'utilisation des outils (en ligne de commande généralement) qui génère, non pas seulement la structure de l'application, mais aussi une bonne partie du code de l'application. Ruby on Rails, Grails et Maven représentaient le début.
La philosophie de ce dernier principe suppose que malgré les grandes différences entre les applications développées, elles peuvent être catégoriser en un nombre limité, et même petit, de types. Les applications de même type partagent toutes la même architecture, le même style et (presque) les mêmes fonctionnalités. Ainsi, il est possible de créer des outils qui peuvent générer une bonne partie de code de l'application en se basant sur son type. Par la suite, le développeur doit introduire les "différences" seulement.
Si je suis en désaccord avec les deux premiers principes, je suis particulièrement contre le troisième. Il cache une simplification à la fois dangereuse et coûteuse.
Dangereuse : parce que la supposition de base est vraiment discutable. Si je ne peux pas prouver qu'il est impossible de catégoriser les applications, il est aussi impossible de prouver le contraire. Tenant compte de cela, il est complètement justifiable de dire que les applications "de même type" ou "similaires" ne sont pas nombreuses et, ainsi, s'investir dans l'acquisition et l'apprentissage d'un outil pour l'utiliser deux ou trois fois seulement peut être une mauvaise décision.
Coûteuse : parce que ces outils reposent sur d'autres plateformes, bibliothèques et services. Ainsi, tout changement au niveau de l'un de ces dépendances peut influencer d'une manière considérables les applications développées.
Ce dernier inconvénient reste toujours présent avec chaque projet (la passerelle ODBC en Java constitue un excellent exemple), mais avec une telle dépendance sur plusieurs couches d'outils et d'API utilisés pour générer, compiler et exécuter l'application en question le risque devient des dizaines de fois plus importants.
Dans cet article, une brève démonstration d'une telle génération en utilisant Yeoman.

De la génération du code à la génération des applications (3/3) : la génération des applications

La génération des applications prend de plus en plus de place dans la pratique de développement aujourd'hui. Le principe repose sur l'idée que les applications de même type (si on suppose qu'une catégorisation efficace peut être proposer pour regrouper les applications de même type) partage assez d'éléments pour justifier la génération de ces éléments d'une manière automatique.
Personnellement, je suis contre une utilisation massive ou sans une prise en compte de risque de cette approche. Le risque principal réside dans la possibilité d'imposer des trop de contraintes techniques sur l'application par la plateforme alors que la situation naturelle est bien l'inverse.
Le deuxième risque majeure est le nombre très élevé des dépendances sur lesquelles la génération et, par conséquent, l'application sont basées. Une justification illustrée est citée sur l'article de discussion.
Dans cet article, je vais donner un exemple sur la génération d'une application avec une partie du code. Ainsi, je ne vais pas faire appel à Grails, Ruby on Rails ou même Maven. Je vais compter sur Yeoman. Un générateur d'applications web. Et lorsqu'on dit une application web ces jours là, alors, on veut dire Node.
Ainsi, l'installation se fait par une commande npm :

npm install -g yo

Il faut installer le générateur à utiliser parce que le package par défaut ne vient pas avec un :

npm install -g generator-webapp

Cela est bien dit dans la documentation officielle. Ce qu'on ne trouve pas si les détails sur les droits ad'accès et le lieu d'installation. En d'autres termes, ils supposent que l'utilisateur metrise bien Node et npm. L'installation prend un moment puisque, encore une fois, le système installe ces paquets et leurs dépendances.
Par la suite, la génération ne pose pas problème :

yo webapp

Et l'application est créée.
Attendez, j'ai dit "pas de problème" ? Bien sûr que non, le système se lance à nouveau dans une procédure de téléchargement des plug in et des paquets. Le problème principale se pose encore une fois parce que les packages principaux de Node sont installés avec des droits d'accès supérieurs alors
qu'on est entrain de créer une application par et pour un utilisateur simple. Apparemment, ce problème est très fréquent au point où un message qui recommande l'exécution avec des droits supérieurs est affiché par défaut. L'enfer n'est pas signalé dans la documentation et vous allez vous trouver avec des

chmod 777 -R 

Pour éviter de trop vous casser la tête.
Par la suite, on trouve que l'application générée dépend sur Gulp, un outil de gestion des dépendances et de construction des projets JS. Si j'ai rien contre Gulp, le fait d'être obligé de l'avoir comme une dépendance en tant qu'outil (et non pas seulement une bibliothèque) me dérange énormément.
Encode une fois, on doit faire appel à npm :

npm install -g gulp-cli

Les mêmes remarques concernant les droits d'accès et les permissions se répètent.
Enfin, l'exécution avec Gulp :

gulp serve

La console :

L'application générée (dossiers) :

L'application générée (résultat) :

La supervision de l'application (intégrée automatiquement et sur un port différent grâce à Browsersync) :

On voit clairement le nombre de clients actuels et les différentes informations pour une meilleure supervision.
Et malgré ce résultat final, je garde mes réserves contre cette approches, surtout lorsque je voit le nombre de fichiers créés et le nombre de dépendances Node intégrées (2689 directories, 20207 files).

Cela ne représente qu'un exemple. Yeoman lui même est une dépendance pour des systèmes de génération plus complexes et qui se basent sur plusieurs couches. JHipster en est un exemple.

De la génération du code à la génération des applications (2/3) : la génération du code

La génération du code est le point fort des EDI. Ces dernier vise à traduire des actions visuelles pour générer un code correct. Cela s'ajout à un ensemble d'outil de gestion des projets et d'édition du code (coloration, auto-complétion, etc.) (point discuté ici).
Dans cet exemple, je vais illustrer cette caractéristique principal des EDI. Pour faire, il n'y a pas mieux que travailler sur des composants graphiques où l'action visuelle est plus parlante. Ainsi, je vais commencer par créer un nouveau projet et par créer une JFrame. Je vais garder en esprit que NetBeans "génère automatiquement" une méthode main pour chaque JFrame.

NetBeans utilise GroupLayoutManager comme LayoutManager par défaut pour gérer le positionnement des éléments. Cela nous donne l'avantage pour gérer d'une façon très souple le positionnement des éléments, néanmoins, cela limite la portabilité de notre code pour d'autres éditeurs.
Ajoutons quelques composants pour voir le code généré :

L'outil nous permet de voir et de modifier toutes les propriétés des composants manipulés. Il nous donne aussi la possibilité de changer des éléments basiques du génération du code tels que les nomes des variables :

Jetons un coup d'oeil sur le code généré :

    // <editor-fold defaultstate="collapsed" desc="Generated Code">                          
    private void initComponents() {

        lblMessage = new javax.swing.JLabel();
        txtMessage = new javax.swing.JTextField();
        btnDisplay = new javax.swing.JButton();

        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);

        lblMessage.setText("Message : ");

        txtMessage.setText("Message to display");

        btnDisplay.setText("Diplay");

        javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane());
        getContentPane().setLayout(layout);
        layout.setHorizontalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGroup(layout.createSequentialGroup()
                .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
                    .addGroup(layout.createSequentialGroup()
                        .addGap(85, 85, 85)
                        .addComponent(lblMessage)
                        .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)
                        .addComponent(txtMessage, javax.swing.GroupLayout.PREFERRED_SIZE, 155, javax.swing.GroupLayout.PREFERRED_SIZE))
                    .addGroup(layout.createSequentialGroup()
                        .addGap(161, 161, 161)
                        .addComponent(btnDisplay)))
                .addContainerGap(71, Short.MAX_VALUE))
        );
        layout.setVerticalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGroup(layout.createSequentialGroup()
                .addGap(53, 53, 53)
                .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.BASELINE)
                    .addComponent(lblMessage)
                    .addComponent(txtMessage, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE))
                .addGap(30, 30, 30)
                .addComponent(btnDisplay)
                .addContainerGap(173, Short.MAX_VALUE))
        );

        pack();
    }// </editor-fold>

Nous voyons que le code généré est un peu lourd, c'est à cause de LayoutManager utilisé.
Nous pouvons changer le LayoutManager en toute simplicité et sans modifier le code directement. Il suffit de faire un clique droit sur l'objet de la JFrame dans le navigateur et de choisir le nouveau LayoutManager de la liste qui s'affiche en pointant "Set Layout" :

Revenant à notre code :

    // <editor-fold defaultstate="collapsed" desc="Generated Code">                          
    private void initComponents() {

        lblMessage = new javax.swing.JLabel();
        txtMessage = new javax.swing.JTextField();
        btnDisplay = new javax.swing.JButton();

        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
        getContentPane().setLayout(null);

        lblMessage.setText("Message : ");
        getContentPane().add(lblMessage);
        lblMessage.setBounds(85, 55, 77, 15);

        txtMessage.setText("Message to display");
        getContentPane().add(txtMessage);
        txtMessage.setBounds(174, 53, 155, 19);

        btnDisplay.setText("Diplay");
        getContentPane().add(btnDisplay);
        btnDisplay.setBounds(161, 102, 78, 25);

        pack();
    }// </editor-fold>  

Ainsi, nous pouvons contrôler facilement le code généré à un niveau très bas et avec toute la liberté, mais, un certain niveau de connaissance et de compréhension du code généré est nécessaire.

Oracle JET : des composants et non pas une framework

Le développement frontend repose principalement sur des framework JS. Ces frameworks peuvent imposer l'architecture à suivre mais aussi le style de développement à suivre, et la question qui vient à l'esprit d'un minimaliste est : Existe-t-il une solution plus légère ? Comment développer ("prototyper") en frontend en utilisant JS sans avoir à faire appel à une framework ?

Cette question me vient toujours à l'esprit à chaque fois que j'essaie de faire une démo rapide et je me trouve déboguer un code JS perdant ainsi un temps précieux en classe.

Ces derniers jours, je me suis retourné vers une technologie (si on peut dire) Oracle à laquelle j'ai tourner le dos depuis longtemps. C'est Oracle JET (Oracle JET). Comme étant intéressé exclusivement par Java et à la limite J2EE (maintenant EE4J), je n'ai pas pas trop concentré sur les autres technologies Oracle. Aujourd'hui, je me suis retourné pour voir est ce que je pourrais trouver une réponse à ma question.

Est-ce que Oracle JET est bel et bien la réponse à la question que j'ai posée ? Oui et Non.

Oui, parce que à la base, Oracle JET est un ensemble de composants et non pas une framework (selon l'explication). Vous pouvez suivre toujours vos propres méthodes, architectures et approches de développement et au même temps avoir une large gamme de composants que vous pouvez intégrer facilement à votre application (liste).

Non, pour les raisons suivantes :

• Oracle JET est basé sur un grand nombre de librairies JS et bien sûre sur Node. Malgré la facilité d'utilisation, le tout doit être à jour et l'outil effectue (presque) à chaque fois des actions de téléchargement; cela devient (avec un peu d'exagération de ma part) inutilisable dans un contexte d'enseignement.
• Le code généré par l'outil ojet-cli est incroyablement grand puisque il intègre le tout, non pas seulement les composants que vous voulez utilisés, par conséquent, un grand travail de nettoyage est nécessaire avant le déploiement (cela reste toujours acceptable dans le cadre d'un prototype).

Pour l'installation, c'est très simple (Command Line Tool):

npm install -g @oracle/ojet-cli

Mais malheureusement, ce n'est jamais aussi simple que ça.
Premièrement, n'oubliez pas de donner le droit d’administrateur à la commande (sudo).

Deuxièmement, si Node n'est pas à jour, alors vous risquez d'avoir des erreurs de syntaxe sur le code généré. L'erreur qui m'est arrivée :

$ ojet build
/home/tarek/JavaPlayground/firstJet/MyFirstJET/node_modules/winston/lib/winston.js:11
const { warn } = require('./winston/common');
      ^

SyntaxError: Unexpected token {
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:374:25)
    ...

Comme vous voyez, cette erreur n'a rien à voir avec Oracle JET mais avec "winston", et à vrai dire, je n'ai jamais entendu parlé de ce "winston" avant ce message d'erreur. Une erreur commune qui nécessite la mise à jour de Node (l'issue). Là c'est pas aussi simple aussi (propositions "théorique", et n).

npm peut rendre npm inutilisable (Oui, apparemment ça arrive)
Ensuite, il faut une installation presque manuelle pour mettre à jour Node et pour récupérer npm qui a tenté de mettre à jour Node.

Une fois tous les problèmes sont résolus, l'application fonctionne à merveille. 

[En Deux Mots] Ne faites pas de longues ruptures

Même si ce conseil paraît évident, j'ai fait cette erreur de ne pas le suivre. J'ai pris une longue rupture qui a atteint les 3 ans, durant lesquelles, je n'ai pas réalisé des projets complets. Mon travail de développement se limitait à ce que j'avais besoin pour assurer les Travaux Pratiques en Algorithmique (pour les étudiants en première année Mathématique et Informatique - MI). Deux ans en Pascal et une dernière année en C.
La cause principale de ce désastre était mes débuts en doctorat. entamer un nouveau domaine n'est pas toujours une chose facile, surtout s'il s'agit d'un domaine loin de l'informatique. Je me trouvais étudier les livres de psychologie, psychopédagogie, psychologie du développement, théorie de l'action et les théories des émotions.

Sloman, A. (2004, March). What are emotion theories about. In Invited talk at cross-disciplinary workshop on Architectures for Modeling Emotion at the AAAI Spring Symposium at Stanford University in March.

Les résultats de cette rupture étaient catastrophiques. Premièrement, mes productions étaient des codes dispersés qui visaient des exercices d'introduction à l'algorithmique, des exemples sur les boucles et quelques exercices très classiques comme la vérification d'une grille Sudoku ou bien trouver les nombres amis. Si mes participations sur les forums des débutants ont devenus plus détaillées et plus pédagogiques, mes participations sur les forums plus avancés commençaient à diminuer avant de s'arrêter complètement. Mon repository sur Source Forge a stagné complètement aussi.
Deuxièmement, je n'ai pas pu suivre du près les nouvelles approches révolutionnaires qui ont vu le jour durant ces années. Groovy était un langage des amateur, Docker était dans ces débuts et semblait avancé un peu doucement et l'école fonctionnelle semblait encore endormie. Après trois ans, Groovy n'est plus le langage pour les amateurs; il est devenu un langage et une plateforme très intéressante. Je ne pouvait même pas reconnaître des parties telles que Grail qui a changé complètement. Docker a aussi changé, maintenant, il est doté d'un écosystème complet et il est devenu la base d'autres plateformes telles que Fn. Cette dernière prouvait qu'une l'approche fonctionnelle est du retour et avec puissance; l'approche Objet sur laquelle je me basais complètement a commencé à montrer sa lourdeur sur le côté serveur.
Finalement, je ne reconnaissais plus ma plateforme préférée : Java (J2SE/J2EE). La J2EE 6 était une vrai révolution, les fichiers XML que j'ai tant utilisé ne sont plus nécessaires et ils sont généré automatiquement à partir des annotations. Les services web RESTful ont devenus plus simples et plus rapides à développer. Les annotations se multipliaient et les outils aussi. Java 8 et les expressions Lambda ont été introduites, je n'en savait rien sauf quelques articles très brefs que j'ai lus.
Comment je me suis réveillé ? Je préparé une formation Java pour des étudiants. C'était avant l'introduction du module Programmation Orientée Objet avec des Travaux Pratiques en Java. Tout simplement, j'ai trouvé du mal à écrire ma fonction main, c'était aussi grave. Durant les deux années suivantes, j'ai essayé de récupéré. Même si je me débrouille pas mal, je pense que tout ce la était facile à éviter si je ne me suis pas émergé complètement dans mon doctorat et mon enseignement.
Alors, Ne prenez jamais de longues vacances et ne faites jamais de grandes ruptures. Restez près de votre éditeurs et travaillez sur des projets, même les plus simples, d'une manière continue. Ne vous contentez pas des articles, installez les nouvelles versions et essayez les, ce n'est pas une perte du temps, c'est même un gain du temps.
(Pourquoi cet article ? Jetez un coup d’œil par ici)

En Deux Mots (une courte série)

Depuis environ 11 ans, j'ai entamé ma carrière en recherche. Le début était avec mon projet de fin d'études (pour en savoir plus, c'est par ici). Par la suite, j'ai décidé de continuer avec mes études supérieures; j'étais fasciné pour le monde universitaire et j'ai voulu l'intégrer. Durant les années qui suivaient (à partir de 2008), je passais d'un ingénieur qui se base sur ses outils conceptuels et techniques pour résoudre des problèmes (plus ou moins) pratiques à un jeune chercheur qui doit s'affronter à de nouvelles problématiques et à proposer de nouvelles propositions. La différence était énorme et le premier résultat était mon éloignement de l'aspect technique de l'informatique.
Après avoir intégré la famille universitaire, le problème continuait. Je travaillais sur la théorie pour ma thèse de doctorat et j'exploitais mes connaissances techniques de base qui étaient plus que suffisantes pour garantir mes responsabilités d'enseignement. Et puisque je n'avançais pas, alors je reculais.
Cette époque de 11 années était marquée, sur le plan professionnel, par une profonde sensation d'incertitude et d'hésitation. Les causes étaient multiples et le résultat était une grande influence négative sur ma concentration et sur mon rendement.
Si je fais un résumé de ma vie professionnel durant ces 11 années, je peux voir que j'ai commis des dizaines d'erreurs que je pouvais éviter facilement pour aller plus loin et pour accomplir beaucoup plus de ce que j'ai accompli. J'ai commis ces erreurs malgré les mises en garde et les avertissements des centaines d'auteurs.
Dans cette courte série, je vais essayer d'écrire à mon tour, pour moi et pour vous, à propos de ces erreurs à éviter. J'écris cette série pour moi parce que tout simplement je sens le besoin de le faire. Je l'écris aussi, pour vous, pour vous avertir et peut-être pour vous aider à éviter de tomber dans ces mêmes erreurs.
Le titre de la série est "En Deux Mots"; elle sera constituée de quelques articles courts (d'où l’appellation). Chaque article sera consacré à une (et une seule) erreur que j'ai faite. 

La prise d'otage sur les réseaux sociaux

Introduction

Les réseaux sociaux sont parmi les outils de communication les plus utilisés aujourd'hui. Combinés ensemble, et en comptant le nombre de personnes atteintes par chaque publication, les réseaux sociaux prennent, effectivement, le dessus sur les autres moyens tels que l'e-mail, le blogging et les forums.
Ces outils reposent sur un ensemble de notions issues de l'ingénierie sociale pour attirer les nouveaux utilisateurs et pour fidéliser les anciens. Ainsi, nous avons vu Facebook se classer comme le site le plus visité au monde pour plusieurs mois (avant de perdre cette position face à Google qui a repris son ancien classement).
Ces notions ont toujours été utilisées dans le marketing et par les différents groupes et organisations pour attirer des clients, des membres, des volontaires ou même des victimes. Le virus "I love you" me vient à l'esprit comme l'une des premières tentatives qui a montré à quel point il est facile de convaincre les gens à prendre une action risquer en exploitant les notions sociales les plus basiques. C'est pourquoi l'étude des réseaux sociaux est un axe de recherche très actif et pour différentes disciplines.
Néanmoins, l'abus de ces règles peut mener à des comportements et des conséquences que les créateurs de ces systèmes n'ont jamais imaginés. Dans cet article, je vais essayer de présenter une observation qui devient de plus en plus fréquente sur les réseaux sociaux et de plus en plus exprimée par les "facebookeurs" dans les différents groupes. Une observation qui me fait l'impression que Facebook est devenu, en quelque sorte, un moyen de prise d'otage durant la communication sur ce réseau.

Les modes de communication

La communication à distance est l'un des ajouts les plus important des réseaux informatiques.  En effet, les deux moyens essentiels de communications connus jusqu'à la mise en oeuvre d'ARPANet étaient la poste (le "mail") et la téléphonie (fixe). Ces deux modes sont de deux natures différentes :
Le mail est un mode de communication lent. Mais, il permet à l'émetteur de prendre son temps pour préparer la lettre (écrites, documents, colliers, etc..) à envoyer. Il lui permet aussi de se libérer après l'envoie et de ne pas rester bloqué pendant l'attente d'une réponse. Ce mode de communication est dit "Asynchrone".
La téléphonie, de sa part, est rapide. Mais, un appel téléphonique nécessite la présence des deux parties impliquées dans la communication. L'émetteur doit envoyer son information dans un délai très court. Il est ensuite bloqué en attendant une réponse. C'est pourquoi tout le monde déteste sa mise en attente lorsqu'on appelle un Call Center. Ce mode de communication est dit "Synchrone".
Pour les deux modes, il ne faut pas oublier une réalité : les deux modes restent secondaires en comparaison à une communication en face-à-face. C'est à dire, une communication suivant l'un ou l'autre de ces modes sera facilement interrompue si l'un des deux parts est déconcentré par une communication en face-à-face avec une autre personne. Personne ne favorisera la lecture d'une lettre si une autre personne présente avec elle dans la même pièce s'engage dans une conversation avec elle. La même affirmation est vrai dans la plus part des cas pour un appel téléphonique.

La communication sur Facebook

Le moyen de communication direct sur Facebook est sa messagerie. Cette dernière se présente comme l'outil le plus utilisé et le plus orienté vers une communication de personne à personne. Les autres moyens visent d'attirer les utilisateurs pour s'engager à des activités sociales. Cela explique pourquoi facebook a lancé une application séparer (Facebook Messenger) et elle n'a pas fait la même chose avec l'espace Market (par exemple).
La messagerie de Facebook supporte les deux modes de communication :
Elle permet un dialogue en temps réel (Synchrone) : la notion d'utilisateur connecté et la réception des messages en temps réel avec une notification sonore et visuelle pour attirer l'attention de l'internaute sont la base de cette fonctionnalité.
Elle permet d'envoyer un message à un utilisateur déconnecté (Asynchrone) : l'envoie de message est possible même si le destinataire n'est pas connecté. Il peut trouver le message qui lui a été destiné lorsqu'il se connecte.

Les nouvelles contraintes

Néanmoins, nous commençons à avoir de nouveaux comportements négatifs sur ces réseaux sociaux. Une fois engagé dans une communication synchrone, il est pratiquement impossible de la laisser sauf en donnant une justification détaillée. Cela représente une mise de pression injustifiée et complètement superflue sur les utilisateurs de ces réseaux.

La mention Vue

La mention Vu indique  l'utilisateur que son destinataire a vu son message. Après avoir vu son impact, je pense que son ajout n'est pas innocent et ne se résume pas à son simple objectif. La signification sociale de ce simple message a passé de "votre destinataire a vu votre message" à "votre destinataire ne veut pas vous répondre, il n'a pas le temps pour vous et il ose penser avoir d'autres choses plus importantes que vous". C'est, à la lettre, une explication donnée par un facebookeur de sa vision pour la mention Vu sans répondre au message.
Une complication qui est devenu une convention. Son risque est le fait qu'elle met encore plus de pression sur le destinataire. S'il ne répond pas, il risque d'offenser ou même de perdre son "ami". Ainsi, en exploitant la nature sociale de l'être humain, et en ajoutant une simple marque 'Vu', le réseau social arrive à "obliger" l'utilisateur à "répondre" et "ne pas quitter la conversation". Autrement, il se voit amené vers un conflit avec ses connaissances sur le réseau.

Temps de réponse

Un autre aspect de réponse largement exploité est le temps de réponse. Je désigne,  ici, par temps de réponse, la durée entre la mention "Vu" et l'envoie de la réponse. Bizarrement, le temps de réponse acceptable devient de plus en plus court. En effet, vous pouvez être "bloqué" si le temps de réponse dépasse les quelques minutes. C'est une autre tendance qui exerce encore plus de pression sur le facebookeur, non pas par le réseau lui même, mais par ses "amis".
Comme pour la mention Vu, cette mesure, qui ne devrait pas avoir une signification justifiée en parlant de la nature de communication Asynchrone, est devenue une mesure du respect et d'attachement du destinataire : "plus la durée est longue, moins il vous respecte et moins il est attaché à vous et plus il est prêt à vous perdre". Pour le mode de communication Asynchrone supposé supporté par la plate-forme, cette affirmation n'a aucun sens.

Conséquence

Ces deux nouvelles contraintes sont basées sur de simples observations. Il est possible de détecter d'autres contraintes qui s'imposent sur les utilisateurs des réseaux sociaux par leurs paires. Ces contraintes viennent pour représenter une pression supplémentaire et pour contrôler le comportement de l'utilisateur.
Pour les deux contraintes notées, il est claire que l'utilisateur sur Facebook doit prêter de plus en plus d'attention à ses discussions sur Messenger. Il doit aussi leur accorder une priorité plus élevée de celle accorder à sa vie réelle, son existence même. Autrement, il risque de perdre ses "amis". Répondre même si vous ne le voulez pas ou bien devoir répondre dans un délai record de quelques minutes veux dire que vous n'êtes plus libre et que vous n'êtes plus dans une communication saine. En effet, vous perdez l'avantage de la communication asynchrone qui vous autorise à avoir votre temps pour répondre et vous perdez l'avantage de la communication synchrone qui est caractérisée par sa rapidité et la facilité de sa terminaison. Vous êtes bloqué dans une communication textuelle, de longue durée, illimitée (ou presque) et obligeante.

Nouvelle pratique ?

Malheureusement, les solutions qui prennent de plus en plus de place entre les facebookeurs ne sont pas dans le bon sens. Il s'agit de quelques solutions pour dévier le problème et non pas pour corriger ces faux jugements donnés à des fonctionnalités basiques sur un système de discussion d'un réseau social. Je vais citer une pratique qui m'a tellement surpris qu'elle m'a poussé à écrire cet article.
Pour éviter l'apparition de la mention "Vu" sur un message ou une discussion, le facebookeur charge la discussion en lançant l'application, ensuite, il désactive sa connexion Internet (que ce soit en Connexion de Données ou Wi-Fi), il visualise la discussion et ferme l'application. Il réactive ensuite la connexion et lance à nouveau l'application de messagerie.
Vous allez penser que c'est pénible. Je suis parfaitement d'accord avec vous. C'est de l'effort et du temps perdus sans une justification valide. Cette pratique ne peut jamais être considérée comme une solution; elle consiste à remplacer l'obligation de répondre par l'obligation de passer par cette procédure pour lire le message sans laisser la mention "Vu".

La véritable solution

La véritable solution est la compréhension de quelques points essentiels :

• Un réseau social est pour communiquer à distance, cela ne doit, sous aucun prétexte, être plus important que la vie dans le monde réel.
• Un réseau social est pour vous laisser en contact avec vos amis. Si l'un d'eux vous fixe des règles ou essaie de vous contrôler par des convention débiles, il ne mérite pas d'être votre ami.
• Communiquer est une action volontaire pour passer un message entre deux personnes. Sauf état de guerre ou une situation d'urgence (question de vie ou de mort), l'activité de communication ne doit pas imposer des pressions ou des obligations; c'est contre sa nature.
• Si une personne lit votre message et n'a répondu, c'est qu'il ne peut pas ou même ne veut pas répondre. Aucune signification injustifiée ne doit être donnée à cette action de ne pas répondre. Vous n'avez pas le droit d'obliger les autres à prendre telle ou telle action. En gardant ce droit aux autres, vous le garderez pour vous-même aussi. 

Conclusion

A la fin, j'ai essayé de mettre le doigt sur des pratiques et des idées qui commencent à devenir une source de pression et de frustration sur les réseaux sociaux. Ces idées obligent les facebookeurs à prendre des actions même contre leur volonté. Elles donnent, aussi, le droit à des gens de juger d'une manière absolue les autres gens en se basant sur une action ou deux, sans justification, ni prise en compte du contexte et des conditions par lesquelles ils passent. Ces éléments détruisent les fondements d'une communication saine qui est supposée être l'objectif même d'un réseau social.
Il est évident qu'une analyse plus profonde peut révéler d'autres phénomènes et d'autres exploitations immorales des notions de l'ingénierie sociale. Est-il temps de commencer à enseigner ces pratiques à nos enfants ?