Le SI parfait est pour demain…chaque jour

Toujours mieux

C’est finalement la conclusion de mes vaines courses après le système d’information parfait où l’information est parfaitement rangée et en fait se range d’elle même sans aucun effort.

A force de continuellement explorer le nouvel outil sympa mais qui s’appuie sur une norme compliquée. Puis finalement une norme  parfaite apparaît et aucun n’outil ne permet de l’exploiter à fond. L’outil arrive mais le matériel utilisé a tellement évolué que ni la norme ni l’outil n’exploite ses capacités. Et puis de toute façons les besoins ont changé et les paradigmes aussi.

La frustration est constante quand on tente de réunir le monde entier au même endroit et au même moment.

Voici ici mes vaines tentatives de disposer du meilleur langage et du meilleur framework, pour mettre en oeuvre les meilleurs normes déployé sur le meilleur matériel pour satisfaire le (meilleur ?) besoin.

la meilleure norme

 

J’avoue que je ne consulte que rarement les RFC et cahiers de normes. Je laisse ça aux gens dont c’est le métiers de les appliquer (créer un navigateur par exemple) et je découvre la norme en au travers de leurs implémentation (comment créer une page dans ce navigateur). Je prend réellement conscience de la norme quand l’outil que j’utilise ne la respecte pas (ma page est superbe dans un navigateur et une horreur dans un autre).

Un système d’information se doit d’être déployés sur des « machines » très variées qui devront mémoriser et échanger de l’information et il sera très probablement construit avec des outils…il est préférable d’avoir une norme commune, pérenne, exhaustive, constante et ouverte…rien que cela !

Il est préférable de choisir les bonnes normes sauf à fournir une solution qui inclue le tout : « voici votre SI de gestion, les ordinateurs, tablette et smartphone pour l’utiliser, le réseau  (cables et bornes radio, routeur, etc…) pour le déployer, le plan de montage et roule ! Une fois prêt on vous envoi les utilisateurs qui connaissent et maîtrise votre besoin. »

Et pas d’illusion : il faudra s’adapter au changement de la norme (Tous en IPv6) ou disparaître (Mais où sont les constructeurs autres que pour BlueRay ?)

Mais alors où en sommes nous en informatique ?

Coté communication

Comment va-t-on faire circuler l’information ?

L’internet et ses protocoles d’origine sont maintenant  suffisants pour échanger de l’information (UDP, TCP, IPv4) et se comprendre (SMTP, HTTP, etc…). Bonne nouvelle ces protocoles couvrent l’essentiel des besoins et sont raisonnablement partagé par les programmeurs du monde. Et celui qui les a connus il y a 5 ans peut encore s’en sortir ; quant à l’inventeur du SMTP (celui qui s’extasiait d’avoir transmis des caractère ASCII à son collègue à l’autre bout du campus…un courrier électronique), il va ramer en recevant aujourd’hui un message contenant une image (en ASCII !).

Ces nanards les plus frais de l’informatiques (j’estime, à la louche, formé depuis 2005) se croyaient à l’abri ? Il va falloir maintenant maîtriser les nouveaux protocoles qui viennent s’intercaler pour régler les problèmes de sécurité. Du SSL/TLS ! du HSTS ! WPA, WPA2, WPAPro, Perso…depuis que les réseaux radio se démocratise.

En somme, aujourd’hui et depuis environ 10 ans, les interfaces réseau, les routeurs et même les applications clientes parlent la même langue…tant qu’elle le parle en clair.

On peut donc s’appuyer sur les normes historiques mais les normes de sécurité sont encore en train de bouger. Et si on ne les suit pas on risque de faire un SI qui sera soit une passoire soit bloqué par les outils.

IPv6 !

Ce sujet ne concerne pas directement la sécurité mais il va y avoir de la casse à mon sens.

Les SI à venir vont probablement se localiser en IPv6 à terme. En attendant, il devra se localiser dans un univers hybride entre les deux. Double challenge pour le type dont le SI ne marche pas :  s’il sais déchiffrer des trames IPv4 et comprendre un problème de routage aujourd’hui…je ne pense qu’il fera ça naturellement en IPv6 (en tout cas j’avoue que moi je rame dure).  A cela s’ajoute la difficulté quand 2 réseaux communique chacun dans leurs langues et qu’il faudra comprendre la rustine utilisée pour les connecter ensemble.

Et l’indépendance des couches OSI me lancent les puristes !? Si c’est bien fait, les applications ne dépendent pas de la couche réseau !

Je n’ai pas parcouru le monde du SI entier mais je n’ai jamais vu quand « c’est bien fait ». Par exemple il n’est pas rare de voir des « applications » réagir différemment selon l’adresse (fournie en paramètre et vérifié si le format est IPv4 est conforme !). Pour ma part j’ai croisé des pelletés de programmes qui utilisent en dure « 127.0.0.1 » (IPv4) et non « ::1 » (IPv6).

Faites comme vous le sentez mais selon la durée de vie prévue autant faire un SI qui roule déjà sur l’autoroute IPv6 car tôt ou tard on ne pourra plus passer par les nationales IPv4 (ou au moins préparez vous-y).

Coté  représentation de l’information

Ce serait bien que tous les outils de communication, de traitement ou d’affichage de l’information comprenne l’info qu’on leur donne.

Et je me trompe peut-être mais la norme XML me semble la plus complète et fiable.

« Et JSON c’est pour les canards !!?? » ne nous méprenons pas : JSON est très bien, très simple et très partagé notamment par tous les langages commun du web (javascript notamment…dont JSON n’est qu’un sous ensemble) et API web (JQuery). La norme est très simple (l’intégralité est défini sur à peine deux pages A4 : http://www.json.org/json-fr.html).

Pour ma part, j’ai un problème de vieux qui pense que les contraintes mises en amont empêchent que ça parte en vrille en aval.

Et JSON c’est autant freestyle que de na pas déclarer le type d’une variable. Rien n’empêche de coller un nom dans une date et finir l’exécution sans que rien ne se voit…pour l’instant. Et la on parle d’objets pas juste une variable.

Peut-être que le principe est que le concepteur met en place tout ce qu’il faut pour qu’il n’y ait pas de boulette et que c’est plus simple à faire que d’imposer des contraintes.

Et d’un autre coté, dans les faits, XML est souvent utilisé au même niveau de contrainte que JSON. Voir même sauvagement converti en JSON plus pratique.

En résumé, XML est une norme tellement ouverte qu’effectivement elle n’a pas besoin d’évoluer (elle pourrait même aujourd’hui se réduire) ce qui lui donne le goût d’une bonne norme.  Et sur le même terrain, la norme JSON est probablement sa rivale et peut-être même son fossoyeur.

Si je concevais un SI, j’utiliserai XML seulement si j’en utilise les rouages qui permettent de spécifier les données (XSD, DTD, XSchema) car au moins ça force à documenter et empêche la propagation de certaines erreurs.  De plus je pourrais exploiter les multiples normes de sélection de l’information (XPath) ou de transformation (XSLT).

Et sinon, j’utiliserais JSON car c’est plus fun et moins lourds et que dans 1 an je serais plus dans cette boites et que les outils de debug on vachement progressés. J’abuse un peu : on peut documenter du JSON et s’assurer du format des données avant toute utilisation…mais dans ce cas autant utiliser XML.

Et pourquoi pas le PDF ?

Hormis XML et JSON, n’oublions pas une autre norme assez partagée pour représenter des données : le PDF !  Et oui : tous les programmes du monde pourraient s’échanger des données en PDF. Mais il faut avouer que les outils pour manipuler les données sont plus rares et PDF est surtout une norme pour imprimer.

En aparté, le PDF est à mon sens un format transitoire, symbole du passage de l’époque du papier et celle du digitale. Dès lors que chacun dispose à tout moment d’un moyen d’accès (i.e. tablette) à une vue de l’information qui est fiable (i.e. contrat) : pourquoi en construire une représentation contenu dans du A4 ? quelle sens ont les notions d’impressions dans un tel modèle ?

Et pourtant, cela fait des années que la banque ne m’envoie plus mes relevés papier et il est acquis que le PDF est une norme d’échange que je saurais lire (ou plutôt que j’aurai des outils pour le faire au moins pendant les soit 5 ans de rétention recommandé).

Certains me diront : et la norme de stockage de l’information ?

Dans la majorité de mes problématiques, c’est un système propriétaire qui assure la persistence (Oracle, MSQL, feu MySQL devenu MariaDB, Google DataStore). L’absence de norme n’a pas été un frein jusqu’alors.

Dans un contexte de données dispersées (Cloud, pair à pair), la question de la norme de stockage est légitime. L’application des normes de sécurité (ou de consentement au moins) est la priorité en cette époque de wikileaks et Snowden. Pour ce qui est de la norme pour l’interopérabilité c’est aussi en cours de rédaction mais ça part déjà dans tous les sens, chaque fournisseur de Cloud fourguant sa bibliothèque de fonctions spécifique).

Je vous avoue que je serais bien embêté s’il fallait décider aujourd’hui déjà d’une stratégie de stockage (Cloud, Pear-to-Pear, centralisé) puis ensuite d’une norme correspondante (Relationnel, Objet).

Jusqu’alors un principe fort contraint ce choix : la propriété de la donnée. Le propriétaire de l’information désire que celle-ci reste en sa possession jusqu’à son aspect physique (serveurs de données hébergé, outils largement reconnus).

Enfin : les principes évoluent. Imaginez, il y a 15 ans j’œuvrais avec peine à déplacer les précieux fichiers clients de VRP dans un SI…aujourd’hui ils utilisent le carnet Google !

Il ne reste plus qu’à choisir LA solution qui va devenir un peu près la norme.

La guerre du stockage dure depuis longtemps et pour l’instant les éditeurs sont assez puissants pour s’éviter un consensus.

Je répondrais : et la norme d’accès aux stockage plutôt

Par contre, la norme dans l’accès à ces données à toujours été problématique et pourtant centrale. La seul norme réellement partagée aujourd’hui  me semble le SQL et chaque outil de stockage fournie sont moteur SQL avec ses spécificités.  Mais c’est déjà pas mal.

Pléthore d’interfaces performantes sont apparues avec le temps (ADO, OLEDB, ODBC, JDBC,…) prenant en charge souvent (pas toujours)  le SQL mais encore avec des spécificités.

Je pense que ce n’est pas pour rien que les framework de développements se vantait de proposer une interface révolutionnaire pour manipuler les données sans s’occuper de leurs accès…le concepteur veut une personne, il aura une personne.

Et comment ? et hop : on tartine une nouvelle interface. Qui s’appuie souvent sur les anciennes !

C’est top : il suffit juste d’apprendre la nouvelle manière de configurer la source de données pour cette interface, juste de définir éventuellement tout le mapping (faudra aussi apprendre comment…mais c’est simple te dit l’éditeur), juste tuner un peu les mapping voir même la base de données car les performances sont horribles, et peut-être juste finalement passer exceptionnellement quelque fois directement en base ou encore construire des fonctions en base pour accelerer…et juste sous réserve de ça…le développeur a plus qu’à écrire Personne = DB.getPersonne(500). Génial !

Et ben allons y : on va migrer notre base de données…on va quand même faire un projet sur 1 an ?! Pour « deconnecter » et « reconnecter » ?

C’est dur je sais mais j’avais tellement foi en J2EE, Websphere/Weblogic, Zend, Hibernate…et même si j’ai abouti à des solutions qui tournent (correctement) je doute que les briques soient aussi indépendantes que promis.

Aujourd’hui ça se complique, le SQL qui persiste reste très étendu mais s’avère peu pratique quand on sort du model de stockage relationnel. Et les base NoSQL se multiplient aujourd’hui. D’ailleurs, je trouve le nom assez ironique : NoSQL pour dire « Not Only SQL »…Si ces bases dominent et que les gens comme moi tellement à l’aise en SQL disparaissent…le SQL sera éliminé. D’autant plus surement s’il ne répond plus au exigences du BigData où le relationnelle présentent beaucoup d’incompatibilité.

En résumé, pour ma part, tant que la données stockée n’est pas manipulé en l’état l’accès à l’information obligera le traitement à se contraindre au stockage et inversement. Et comme la tendance est aujourd’hui à tout stocker et ça servira bien tôt ou tard, l’accès aux données et leur stockage sont un problème à résoudre mais une norme est-elle requise?

Dans ce domaine, je préfère une solution éprouvée qu’une solution standard. Mon SI devra fournir sa solution pour travailler avec au moins les stockages les plus répandus. C’est du travail (à créer puis à maintenir) mais c’est à mon sens la plus fiable, la plus performante et la moins coûteuse à terme.

Le SI sera probablement encore longtemps composés des 2 socles : Relationnel et Objet qui entraînera même la probable duplication d’une partie du SI.

Le meilleurs outils de développement

Tout le monde sait comment on va parler, en quelles langues et sous quelle forme et  tout le monde sait où on mémorise. C’est parti on construit.

Et là c’est le drame ! Quelle langage (et donc outil) utiliser ?

J’aurais pu inclure ça dans les normes de programmation tant il y a eu de philosophies de la programmation, décrite par de multiple norme, précisé encore dans des normes plus complète d’implémentation (J2EE par exemple). Puis des environnements de développement (IDE comme JBeans, Delphi, Eclipse) accompagné des briques (Librairies, Framework) respectant ces implémentations ont imposés des langages propres.

En 2003, on sortait encore du Cobol (en fait on envoyait sa maintenance à l’étranger) quand j’arrivai avec mon Java et mon C…et mon BASIC. Et là, la programmation événementiel c’est démentiel (Turbo Pascal avec Delphi 5 que du bonheur). Et puis finalement VB c’est plus facile et sa manière de coder est fantastique. Puis c’est l’heure du C++ et Java fait son retour avec de nouveaux framework. Un peu de VBA pour le fun et du PL/SQL et SQL pour la débrouille. Terminé les amis, maintenant on ne développe plus pour postes en local mais pour des serveurs avec quasiment rien sur le poste…juste une petite applet quand même. Non ! en fait plus rien sur le serveur, il va falloir bosser ton JSP, ASP et PHP. Et puis finalement XPath et XSL permettent des trucs pas mal. Puis in va tricher un peu en mettant un peu de trucs chez le client (ActiveX et Javascript et VBScript). Puis ça dérape : on gâve coté client avec des CSS et du Javascript et les librairies disponibles (HttpRequestJQuery est ses fonctions asynchrones !).

De nos jours, le navigateur est devenu le client lourd standard. Il formate le HTML5 couplé avec le CSS. Javascript permet l’interaction avec notamment les multiples bibliothèques disponibles : JQuery, les API Google par exemple (Maps, Calendar, Contact…). Coté serveur on fait encore du PHP ou .NET mais on dirait que javascript se popularise (Node.js fait tout le travail du serveur). Les échanges se font en JSON ou XML simple.

Les programme manipulent presque tous des Objets (qui collent encore plus ou moins à la philosophie du développement Objet) et sont loin d’être séquentiels. Le déroulement est asynchrone et orchestré par les événements.

Si je peux permettre une prédiction : coté client les navigateurs continuent de se conformer aux normes HTML5. la partie cliente s’appuie essentiellement sur l’incontournable JQuery et est composée d’appel à diverses API indépendantes et délocalisées.  Le mode de développement par événements se répand, le système est asynchrone. Ce modèle s’optimise et se fige. L’évolution se fait au travers des services et de leur interconnexion.

En attendant, à mon sens, le coup d’avance c’est Node.js / Javascript / CSS / HTML5 / API Web

Il ne reste plus qu’à trouver le bon IDE (programme de …programmation) qui permet d’écrire cette langue pas trop n’importe comment.

Le meilleur outils d’interaction entre les hommes

Bien : nous parlons tous français et avons des pigeons pour s’envoyer des message. on a même un responsable des messages qui réceptionne les pigeons et brûlent les messages inutiles pour nous.

Du jour au lendemain on remplace les pigeons par des smartphones avec une applications qui blackliste.

Sans trop m’avancer je pense que la teneur de nos conversations vas changer.

Nous avons vu effectivement que les normes et les langages changes mais le principale moteur de cela c’est la technologie disponible.

En 1990, une norme de transfert de streaming vidéo Haute définition pour la VOD n’avait pas de sens. Aujourd’hui toute SMART TV balance les flux vidéo d’un fournisseur quelconque.

De nos jours, le support ultime a quasiment tout pour recevoir et pour reporter : en plus d’un écran, d’un HP et d’un micro, on trouve banalement sur un smartphone un GPS, une caméra, un tachymètre, un altimètre, un gyroscope, un compas, un infrarouge…

Et demain, tout ça se peut se retrouver sur n’importe quelle objet qui sera connecté.

Les normes et les langages évoqué sont apparus dans un monde ou l’ordinateur est fixe et limité. Ces normes et langages semblent avoir englobé les possibilités des matériels actuels mais seul les génies connaissent l’avenir qu’ils vont inventer.

Il ne serait pas étonnant qu’un système d’exploitation complémentent réfléchi dans un univers d’objets connectés nous surprennent bientôt et par là tous les outils qui l’accompagneront.

IBM a déjà mis à disposition un service permettant de récolter les données de diverses capteurs pour en sortir des états.

Si je concevais un SI, ce serai prioritairement pour des smartphones, tablettes et phablettes (J’enfonce une porte ouverte) puis ensuite pour les postes fixes. d’un coté pas trop d’inquiétude, il semble tous s’orienter à respecter les normes du web (HTML5, Javascript). Mais j’oublie l’idée de faire le même outils pour tous (le suivi complet de ma demande sur montre connectée c’est moyen).

Les besoins et les mentalités

Et voilà ! notre SI parfait fluidifie la réalisation du besoin de souscription d’un contrat de Juan au Brésil par Wladek en Pologne.

Mais les hommes sont exigeant et quand on voit un truc bien dans un domaine on s’attend à son équivalent dans un autre. Mais il n’a pas été aussi évident de passer de la facilité d’acheter sur Amazon (en 3 clics) à la facilité de souscrire un contrat dans l’assurance ou la facilité d’avoir un taxi.

Aucun outil ne le fera si le besoin ne s’adapte pas.

Comment passer d’un outil à 5 écrans, 50 informations, 500 points de contrôles pour garantir un contrat en 3 clics sur smartphone ? Et bien sûr l’utilisateur doit voir TOUTE les informations…mais bien sûr de manière concise.

Impossible si la mentalité de celui qui fait ça depuis 20 ans ne change pas. Comment peut-il accepter :

  • On ne présentera que les quelques informations essentielles et pas tout.
  • Le contrats seront complétés après la signature
  • On enlève des points de contrôle et 10% des utilisateurs qui ont souscrit n’aurais pas du.
  • On envoi un mail (pour pas dire courrier) dans lequel il y des phrases générique (« Madame, Monsieur, » ) qui quelque fois ne correspondent pas à la situation.
  • On aura des cas incorrectes mais une plateforme s’en chargera et peut-être pas de la manière la plus optimal

J’admet qu’en tant que client ces choix m’exaspère quelquefois mais souvent le problème se résout.

Je crois que le grosse révolution de l’informatique est en cours : les SI ne garantisse pas 0% de taux d’erreur. Au contraire, ils garantissent même qu’il y en aura.

Résumons

Pour un SI parfait aujourd’hui il faut au moins :

  • Faire des solutions distinctes par support (la même pour tous « en attendant » peut s’avérer catastrophique).
  • Se préparer à recevoir des informations très variées au fur et à mesure. Et se préparer à les restituer (Le BigData !)
  • Tordre les mentalités pour accepter d’adapter le besoin aux support.
  • Satisfaire aujourd’hui le besoin par une solution full WEB (HTML5, Css, Javascript et API, Node.js). Communiquer en XML ou en JSON.
  • Trouver l’environnement de développement idéal qui traite le HTML5, le javascript, le Css, le XML, le JSON et fait respecter les normes !
  • S’appuyer sur les normes d’origine du WEB, fonctionner en IPv4 et IPv6.
  • Intégrer les normes de sécurité sans trop de rigidités (je sens que ça va encore bouger)
  • Créer des modules de SI et non un SI à l’image des Apps.
  • Essayer de développer sa propre interface d’accès au données au moins pour Oracle, SQLServer et MySQL (ou la solution du client).

Il y a bien encore quelque points clés que ne vois évoqués nulle part mais je les gardent pour moi. Vous pourrez les lires dans mon interview dans Forbes…ou le « Monde Informatique » quand ces points traité par mon parfait SI m’auront rendu célèbre. Sinon, c’est que ces points clés ne font finalement pas tant la différence.

Mais aujourd’hui, restons humble : si votre SI n’est que presque parfait, c’est qu’il dispose d’une petite cicatrice où les mesures d’exceptions vont se multiplier et véroler le reste.

Mais demain une révolution nous donnera les moyens de recommencer et cette fois ce sera parfait.