POC d’un système de réservation pour un concert

L’application des consignes sanitaires…peut être très contraignante :

D’où l’idée de mettre en œuvre une réservation préalable.

Mais comment recueillir des intentions de présence fiables pour un concert gratuit ?

La solution retenue a été de transmettre un code de réservation par SMS.

Et de contrôler les entrées (et la limite de remplissage) avec les codes présentés par les personnes à l’entrée.

Bilan

44  des 48 places possibles ont été réservées en 4 jours seulement. Ensuite le site présentant le concert a affiché “Complet !”. Les 4 places restantes ont été mises de coté et utilisées pour accueillir des spectateurs n’ayant pas réservé de place.

Parmi les 22 numéros de téléphone portable saisis pour ces réservations, 4 étaient erronés et n’ont donc pas reçu de code par SMS.

Sur les 18 codes de SMS envoyés, 3 n’ont pas été confirmés ; au moins pour d’entre-eux, il s’agissait manifestement d’une erreur de saisie de numéro puisque une demande de réservation a été confirmée ensuite avec un numéro presque identique (1 seul chiffre différent).

Il était possible de réserver 1 à 4 places par numéro de téléphone portable. Un groupe de 12 personnes a utilisé 3 portables pour réserver ses places.

Personne ne s’est présenté avec un code non confirmé.

Il aura malheureusement fallu refuser du monde pour ce concert mais l’idée de recueillir un engagement pour une entrée gratuite en demandant un numéro de téléphone portable a donc été validée par cette expérience.

Et, par ailleurs, le concert a eu beaucoup de succès !

Et en C++ ?

La comparaison entre VBA, Phyton, PHP ou C restait dans un style procédural. Et si on s’aventurait dans l’orienté objet ?

Allez changeons de paradigme, attention c’est bestial :
Zouen Orienté Objet !

On pourrait transcrire le code en C quasi directement en C++. Après tout, les méthodes des objets sont écrites dans un langage procédural. Mais ce serait sans intérêt et contraire à la philosophie de l’orienté objet. En OO, l’approche quitte nécessairement le procédural pour aller dans le conceptuel…

Comment un développeur OO voit une grille de sudoku ? Comme ça :

C’est à dire sous la forme de 9 régions, elle-même composées de 9 valeurs ; un embryon de structure fractale. On définit alors deux classes :

  • une classe pour les régions,
  • une classe pour la grille d’un sudoku.

La classe Region


Une instance de la classe Region contient quelques attributs privés :

  • une grille de 3×3 valeurs comprises entre 0 et 9
  • une position d’une case courante dont les coordonnées en ligne, colonne sont mémorisées par deux entiers l et c.

Et quelques méthodes triviales (c’est  à dire dont les noms devrait suffire à évoquer leurs fonctions), à quelques exceptions près :

  • suivante() passe la case courante à la position suivante et retourne un booléen “vrai” si on atteint la dernière case ou “faux” sinon,
  • teste(v) vérifie si la valeur v est adaptée à la position courante,
  • ajoute(v) affecte la valeur v à la position courante et passe celle-ci à la case suivante,
  • dup() crée une copie d’une instance,
  • val(l,c) retourne la valeur de la grille privée en ligne l et colonne c (indépendamment de la case courante).

La classe Grille


La classe Grille est à peine plus complexe.

Son constructeur commence par dresser la liste de toutes les régions possibles :

______#0

 

______#1
1 2 3
4 5 6
7 8 9
______#2
1 2 3
4 5 6
7 9 8
______#3
1 2 3
4 5 6
8 7 9

 

...

 

______#362879
9 8 7
6 5 4
3 1 2
______#362880
9 8 7
6 5 4
3 2 1

Il n’y en a que 9! (plus une pour la région vide, une quantité négligeable pour le développeur OO) dont le nombre est mémorisé dans l’attribut publique nbRegions et chaque cas possible dans le tableau Regions de pointeurs sur des instances de la classe Region. C’est la méthode privée listeRegions() qui est chargée de renseigner la liste des régions possibles.

Par ailleurs, la classe Grille contient quelques attributs et méthodes privés :

  • un tableau de 3×3 régions choisies chacune parmi les 362 881 régions possibles,
  • une grille de 9×9 valeurs comprises entre 0 et 9 qui correspondent au choix des 9 régions, mise à jour grâce à la méthode privée enGrille(),
  • les contraintes à respecter pour le sudoku recherché,
  • une position d’une case courante dont les coordonnées en ligne, colonne sont mémorisées par deux entiers l et c.

Les méthodes publiques de la classe Grille font ce que leur nom exprime, valide(r) étant l’équivalent de teste(v) de la classe Region.

La beauté d’un code OO

Une fois ce travail préliminaire effectué, la recherche d’une solution pour un sudoku est spectaculairement concise et lisible :

C’est si beau qu’on en pleurerait d’émotion.

Les horreurs cachées

L’envers du décor l’est beaucoup moins.

Un travail considérable

Même en se contentant de l’encapsulation de l’approche OO (on laisse de coté les notions d’héritage et de polymorphisme), les 113 lignes de code de la solution en C sont remplacées par 365 lignes réparties en 5 fichiers (region.h, region.cpp, grille.h, grille.cpp et sudoku.cpp).

Un résultat lamentable

Les toutes dernières version de Python, PHP et C++ n’étant pas disponibles sur le serveur utilisé pour les tests de performance de l’article précédent, on les refait sur un serveur fraichement installé (Centos 8 en l’occurrence) :

  • 3 s en Python3,
  • 1 s en PHP 7,
  • 0,04 s en C,
  • 45 s en C++ !

A propos, la première solution trouvée en C++ est différente de celles trouvées dans les autres langages :

 2 1 4 3 6 5 8 9 7
 3 5 6 7 8 9 1 4 2
 7 8 9 1 4 2 3 5 6
 4 9 5 2 1 7 6 3 8
 8 2 7 9 3 6 4 1 5
 1 6 3 8 5 4 7 2 9
 6 7 2 4 9 1 5 8 3
 5 3 1 6 2 8 9 7 4
 9 4 8 5 7 3 2 6 1

Voilà un très bel exemple pour la loi de Less 🙂

Conclusion

Il ne faudrait surtout pas jeter le bébé avec l’eau du bain : en déduire que l’approche orienté objet serait inefficace serait une grave erreur !

Car ici, dans le cas particulier de la résolution d’un sudoku, elle est inadaptée. C’est un problème trop simple.

Pour d’autres situations plus complexes, l’approche orienté objet apporte bien au contraire une vision salvatrice, comme suggéré par la simplicité du code principal de résolution d’un sudoku en C++.

Sans oublier que les programmes conçus pour ces tests sont certainement perfectibles.

(Sources des exemples de code)

VBA, Python, PHP ou C : c’est pareil ?

Prenons un exemple quasi idéal pour un traitement informatique : le sudoku.

La première préoccupation de l’informaticien est de choisir une représentation des données et de préciser les interactions avec l’utilisateur.  Le sudoku étant une grille de nombres, on saute sur la facilité en choisissant d’emblée le contexte d’un tableur.

En VBA

Pour repérer les contraintes initiales on les met tout simplement en gras ; par exemple :

Voici alors une solution en VBA de ce problème :

Non seulement c’est illisible mais en plus c’est lent mais alors lent de chez lent.fr !

7 minutes (et 32 secondes) ! Il faut être patient et avoir confiance en la validité du code car Excel devient comateux pendant la durée du traitement.

Mais bon, ça fait le boulot ; voici la première solution trouvée :

Il faut avouer que les contraintes de ce sudoku ont été vicieusement choisies pour nécessiter un grand nombre d’itérations.

En Python

Considérons une version de ce traitement plus pédagogique, écrite cette fois en Python :

Et la même solution est obtenue en seulement 2.2 secondes :

 2 1 4 3 6 5 8 9 7
 3 5 6 7 8 9 1 2 4
 7 8 9 2 1 4 3 5 6
 4 9 5 1 3 7 2 6 8
 8 2 7 9 4 6 5 1 3
 1 6 3 8 5 2 7 4 9
 5 7 1 4 9 3 6 8 2
 6 4 2 5 7 8 9 3 1
 9 3 8 6 2 1 4 7 5
Trouvé en 1453557 itérations.

Le Python a en plus l’avantage d’imposer la présentation du code, ce qui en rend la (re)lecture plus accessible à tous (même à son auteur lorsqu’il doit y revenir plusieurs années après).

En PHP

Pour le fun, le même traitement mais en PHP :

Malgré une petite optimisation du traitement qu’un regard attentif aura repéré aux lignes 23-26, c’est un tout petit peu plus lent : 2.7 secondes.

C’est d’ailleurs cette proximité de temps de traitement qui aura motivé la recherche (empirique) de contraintes nécessitant un grand nombre d’étapes (itérations) pour obtenir une première solution, pas moins de 1 453 557 étapes de traitement pour trouver une première solution qui satisfait les contraintes choisies pour l’exemple.

En C

Mais alors en C, cela donne quoi ?

0,08 secondes.

Si, c’est bien 8 centièmes de secondes… c’est à dire plus de 5600 fois plus rapide qu’en VBA et 200 fois plus rapide qu’en Python !

En prime le code est bien plus beau :

Une démarche commune

Ces quatre exemples ont en commun un style de programmation procédural (à opposer par exemple à une approche orientée objet) et la démarche du traitement.

La grille du sudoku est gérée informatiquement dans un tableau dont chaque case, repérée par ses indices de ligne (l) et de colonne (c) contient la valeur numérique (v) du chiffre qu’elle contient. Un 0 code pour une case vide.

Le traitement est réparti en deux fonctions :

  • valide(v,l,c)
  • cherche(v,l,c)

La première fonction vérifie la validité d’une valeur v mise dans la case (l,c). On y vérifie que la valeur v n’est pas déjà présente sur la ligne l, ni sur la colonne c ni dans la région de 3×3 cases à laquelle la case (l,c) appartient.

La deuxième fonction est récursive (elle s’appelle elle-même). Elle cherche d’abord quelle valeur serait valide dans la case en cours et elle s’assure ensuite que cette valeur est compatible avec une solution pour le reste de la grille, à commencer par la case suivante. Si cette deuxième condition n’est pas vérifiée, on essaye une autre valeur. Si on a épuisé toutes les valeurs possibles, on remet en cause la valeur choisie à la case précédente.

Et si on arrive à trouver une valeur valide pour la dernière case de la grille, on a trouvé une solution !

Des différences de “détails”

Mais écrire ce même traitement en VBA, Pyhton, PHP ou C n’est pas du tout la même histoire.

La solution en VBA comparée à celles en Python, PHP ou C se singularise par sa dépendance au contexte d’Excel. La différence saute aux yeux.

Les solutions en Python, PHP ou C se ressemblent beaucoup plus. Elles comportent néanmoins des subtilités qui pourraient faire perdre un temps fou à l’expert d’un de ces langages qui voudrait en utiliser un autre dont il est moins familier.

Quelques exemples :

La structuration du code

Les blocs d’instruction en Python sont définis par l’indentation (le décalage par rapport à la marge de gauche) et par des accolades en PHP  ou en C. Cette contrainte de présentation du Python que l’on avait aussi en Fortran est une gène pour le programmeur expérimenté et isolé mais une aide pour le débutant ou les équipes de programmeurs.

La gestion des variables

En C, il faut déclarer préalablement chaque variable et préciser le type de données pour lequel elle sont prévues. Il faut  même réserver (et ensuite libérer) explicitement de l’espace en mémoire dans certains cas (non illustré dans l’exemple).

En PHP, les variables sont identifiées par un $ et gérées automatiquement. On peut même utiliser la même variable pour y stocker des types de données différentes. Par rapport au C, c’est cool mais on se retrouve avec des $ partout.

En Python, les variables sont identifiées et gérées automatiquement.

Il y a aussi des différences sur la visibilités des variables. En C, les variables globales sont visibles partout ; une joyeuse source d’erreur. En Python ou PHP, il faut les introduire dans les fonctions avec le mot clé “global”.

Cette évolution de la gestion des variables va dans le sens de la simplicité pour le programmeur. Un des prix à payer est une concession sur les performances.

Les aspects plus techniques

La différence entre le Python, le PHP ou le C est encore plus grande pour des aspects plus prosaïques mais néanmoins incontournables.

Les exemples donnés en illustration les masquent pudiquement. Il s’agit notamment des instructions qui affichent la solution trouvée ou, plus encore, qui initialisent la grille du sudoku et ses contraintes. La maîtrise de ces aspects plus techniques fait toute la différence entre un développeur débutant ou expérimenté ; et cela n’a rien à voir avec une question de syntaxe !

Il y a aussi une autre nuance importante qui distingue le Python ou le PHP avec le C. Les deux premiers langages sont interprétés, le C est compilé. Cette étape de compilation assure un gain de performance considérable à l’exécution mais entraîne une complexité et une charge supplémentaire pour le programmeur.

L’art de l’informaticien

Ce n’est pas la maîtrise d’un langage qui fait l’informaticien, pas plus que l’usage d’une souris ou d’un clavier ni la connaissance d’un “framework” ou d’un IDE.

Au final, l’ordinateur exécutera systématiquement et à un vitesse sur-humaine des instructions élémentaires (chaque instruction réalisant une action ridiculement simple).

L’art de l’informaticien s’exprime dans la conception d’une démarche de traitement bien adapté pour résoudre un problème donné.

Et c’est universel.

(Sources des exemples de code)

Protection de l’intégrité d’une facture

Avant, la modification des factures de numerunique était “protégée” par un mot de passe.

Protection toute relative d’ailleurs, à voir la pléthore de services de déverrouillage de .pdf disponibles sur Internet.

Désormais, ce dispositif est remplacé par un code de hachage :Facture protégée par un code de hachageC’est une série de chiffres hexadécimaux (0-9 ou a-f) qui sont le résultat d’une fonction de hachage des éléments essentiels de la facture :

  • numéro,
  • date,
  • nom du client,
  • montant HT,
  • TVA,
  • objet(s) de la facture.

Pour vérifier cette empreinte numérique, il suffit de recalculer ce code à partir des informations sur la facture et de comparer le résultat avec le code qui y figure. La moindre modification des éléments utilisés pour générer le code entraînerait la génération d’un code de hachage différent.

Pour un numéro de facture donné (numéro qui est unique), il n’y aura donc qu’un seul code de hachage valable. Ce qui permettra de vérifier si les éléments essentiels de la facture ont été altérés ou non.

Si le code de hachage qui figure sur la facture ne correspond pas à celui que l’on peut calculer à partir de ses éléments essentiels ou à celui de l’original de la facture, la facture a été altérée.

Sinon, elle est intègre.

Mieux protégé mais moins accessible

A l’origine de l’Internet  tout était plus simple.

Les premiers sites,  au début de l’ère d’Internet, partageaient des informations directement accessibles dont l’adresse de contact, équipée du lien “mailto:”. Un simple clic sur ce lien ouvrait le logiciel de rédaction de mail avec l’adresse du destinataire pré-renseignée.

Comme c’était pratique !

Le “mailto:” existe et fonctionne toujours mais il est fortement déconseillé de l’utiliser, sauf bien sûr si l’on tient à collectionner les spams. Le web est en effet davantage parcouru par des robots que des humains et détourner la finalité du lien “mailto:” est d’une commodité déconcertante pour un robot spammeur.

Le lien “mailto:” a été d’abord remplacé par un formulaire de contact qui avait le double avantage d’avoir l’opportunité de recueillir quelques informations et d’entraver les robots spammeurs.

Mais les spammeurs ont manifestement appris à utiliser les formulaires de contact.

On a alors vu apparaître des tests de Turing inversés, sensés discerner les humains des robots, sous diverses formes toutes horripilantes et certaines infranchissables. Le site de numerunique a eu le sien, discret mais efficace, en tout cas dans un premier temps.

Malgré quelques améliorations subtiles et aussi peu dérangeantes que possible pour les vraies demandes de contact, les spams sont réapparus inexorablement. Un reportage sur les plateformes numériques en a éclairé la cause probable : de pauvres hères  sont recrutés sur Internet pour résoudre ces tests barrières en contrepartie d’une rémunération dérisoire.

C’est pourquoi l’accès au formulaire de contact du site de numerunique est désormais accessibles aux seuls utilisateurs identifiés. C’est efficace, du moins pour le moment.

Mieux protégé ou plus accessible ? Ce choix requière un arbitrage délicat. Mais une demande de contact anonyme a peu de chance de présenter le moindre intérêt. C’est cette considération qui a emporté la décision pour un site mieux protégé mais moins accessible.

Une alternative au tracking des GAFAM

Dans la même veine que l’article précédent, après la surveillance des contacts rapprochés  (ou le contraire), on pressant une surveillance encore plus précise et généralisée de la position de tous grâce à nos smartphones, oui, encore eux.

Et dire que l’on dépense volontiers des sommes considérables pour s’équiper de ces précieux dispositifs qui menacent nos libertés et notre vie privée !

Donc il est fort probable que nous serons bientôt tous étroitement suivis officiellement. Il est tout aussi certain que nous le sommes déjà officieusement, mais on aurait pu continuer à préférer ne pas s’en apercevoir.

Malgré tout, la géolocalisation a du bon et il ne faudrait pas se priver d’en profiter. Les solutions pour le faire sont très nombreuses mais celles “offertes” par les GAFAM ou affiliés sont encore plus suspectes que nombreuses.

Alors numerunique propose un service avec comme préoccupation principale le respect de la vie privée et comme motivations initiales deux cas d’usage :

  1. rassurer ses proches sur la bonne progression d’un déplacement,
  2. faire patienter un rendez-vous.

Le deuxième consiste à donner une visibilité sur l’arrivée imminente pour un rendez-vous. Plutôt que de se dire “Mais que fait-il ?” la personne qui vous attend peut voir où on en est.

Le point premier cas d’usage est celui qui a été utilisé comme test en situation réelle du service à l’occasion d’un parcours récent : un trajet des Alpes vers le Nord. Qui n’a pas souhaité rassurer sa mère, son épouse et son fils sur le bon déroulement d’un long trajet en solitaire ? Et c’est justement le contexte de ce voyage.

La carte ci-dessus était la partie accessible aux intéressés et l’affichage ci-dessous est une copie d’écran du service qui a permis de rapporter automatiquement le bon déroulement du voyage.

Il s’agit simplement de la page d’accueil d’un site Internet (https://geo.nun.tf) qui permet d’exploiter la géolocalisation accessible à tous les navigateurs (Firefox en l’occurrence).

Un traitement local récupère la position obtenue avec le GPS du smartphone et la transmet au serveur qui héberge geo.nun.tf.

Celui-ci enregistre dans une base de donnée les positions successives et restitue la progression sur une carte sur simple demande de visualisation de la page associée au suivi (geo.nun.tf/123.2133 pour l’exemple ci-dessus).

C’est aussi simple que cela et le mieux pour s’en faire une idée est de l’essayer en allant sur https://geo.nun.tf.

Mais comment cela respecte-t-il la vie privée de son utilisateur ?

Et bien :

  • Les positions transmises entre le smartphone et le serveur sont chiffrées.
  • Le serveur qui héberge ce service est situé en France et est hors de contrôle des GAFAM, bien entendu.
  • La cartographie est assurée par OpenStreeMap, un système libre et ouvert.
  • Ce service n’utilise pas de cookie,
  • ne demande pas de login,
  • ne recueille aucune donnée personnelle,
  • ne partage rien avec aucune autre société,
  • ne fait aucune exploitation commerciale des suivis enregistrés.
  • Il ne fonctionne que si la localisation du smartphone est active et autorisée pour le navigateur, si la page pour la transmission des données est active et si le smartphone n’est pas en veille. C’est d’ailleurs justement à cause de cette dernière contrainte que la première partie du voyage inaugural est en pointillé.
  • Seuls ceux auprès de qui le lien unique vers la carte de suivi a été partagé ont accès au suivi.
  • Et pour finir, les positions enregistrées depuis plus de 24 heures et les traces sans positon depuis plus de 12 heures sont supprimées tous les jours.

Et en plus il est possible d’utiliser ce service librement et sans surcoût puisqu’il n’y a actuellement aucun moyen de payer pour cela !

Une alternative à l’application StopCovid

StopCovid dont il s’agit ici est l’application que nous serons encouragés à installer sur nos smartphones et dont la disponibilité fait partie des contraintes qui conditionnent le déconfinement.

Cette solution présente quelques inconvénients, en plus des difficultés techniques qui en retardent la réalisation.

C’est une “application” et donc son installation implique l’identification précise de son utilisateur, ce qui génère des inquiétudes légitimes par rapport aux libertés individuelles.

Il est prévu que StopCovid relève automatiquement nos rencontres grâce au Bluetooth, ce qui pourrait être gênant et inefficace.

Gênant par exemple si elle trace une rencontre avec son amant, sa maitresse, son médecin, avocat ou dealer…

Inefficace si on se place par exemple sur le quai d’une station de RER et que l’application enregistre tous les identifiants des passagers qui défilent devant soi sans qu’il y ait eu le moindre risque de contact ni de contamination.

On retient les aspects les plus positifs de son cahier des charges qui en motiveront sans doute l’usage :

  1. être prévenu si l’une des personnes que l’on a croisé récemment est tombée malade,
  2. prévenir les personnes que l’on a rencontré si on tombe soi-même malade.
  3. préserver sa liberté.

Pour répondre à ces objectifs, numerunique propose donc une alternative, illustrée par la maquette mise à disposition pour cela.

Ue solution alternative à StopCovid

Il n’y a rien à installer. Tout est volontaire. Rien de personnel n’est divulgué.

Le simple fait de visiter cs.nun.tf attribue aléatoirement un identifiant unique que rien n’associe avec personne. Cet identifiant, représenté par un qrcode, est mémorisé localement sur le navigateur utilisé sur le smartphone et sur le serveur de cs.nun.tf.

Lorsque que l’on croise une personne avec laquelle on a choisi volontairement de partager les intentions 1 et 2 ci-dessus, il suffit de scanner son qrcode (ou l’inverse, un seul scan suffit) pour mémoriser la rencontre qui sera effacée automatiquement 14 jours après.

Pour signaler que l’on est malade, il suffit d’activer le bouton :

Si l’une des personnes dont on a mémorisé la rencontre il y a moins de 14 jours se déclare malade, le fond vert deviendra orange ; il suffit de rafraichir la page sur le navigateur de son smartphone pour le savoir.

En 2020 numerunique se simplifie

Un 0 fusionné avec un 1 pour former un objet réel et unique, ici fait en loupe d'orme

Le bit 3d en loupe d’orme, emblématique de numerunique

Créée il y a déjà plus de 12 ans, l’EURL Barme a choisi sa dénomination sociale d’après le nom de son gérant. C’est direct, simple, pratique et cela permet d’éviter la taxe INPI.

Barme c’est aussi simple et rare mais, pour évoquer l’activité de la société Barme, il y a mieux : d’où le nom commercial numerunique choisi il y a seulement 3 ans.

numerunique c’est top mais, pour faire simple, il y a mieux : d’où sa contraction en nun, plus facile à épeler, entre autres.

Pour encore simplifier, on pourrait s’en tenir à u mais les noms de domaine en u sont pris ou disponibles mais alors avec un tld (top level domain) long et ils sont tous très chers. Le u est apparemment très couru.

D’ailleurs nun.fr est déjà pris aussi quoique pour une activité apparemment obscure.

C’est donc sur nun.tf que l’on peut retrouver numerunique plus simplement. La terminaison tf est pour le tld des Terres Australes et Antarctique Françaises (TAAF) où l’on trouve plein de taf et où numerunique est aussi implantée depuis 5 ans (depuis le 01/04/2015).

Comme quoi, on peut être très sérieux et avoir de l’humour.

 

Loi de Leess et syndrome de l’usine à gaz

La loi de Leess est inspirée de la loi de Moore ; more or less.  Ces deux lois n’ont rien de légal et encore moins de scientifique mais donner son avis sous forme d’une “loi”, ça le fait.

Si l’on considère l’évolution de la performance des ordinateurs au cours du temps, on prétend qu’elle double tous les 18 mois (“loi” de Moore).

Mais si l’on considère l’évolution de la performance des logiciels, on constate qu’elle reste stable (dans le meilleur des cas).

D’où la loi de Leess qui constate que la performance des programmeurs (maintenant appelés développeurs) est divisée par 2 tous les 18 mois.

On pointe ici du doigt les programmeurs mais c’est toutes les couches sous-jacentes qui sont concernées : système d’exploitation, langages de programmation et méthodes.

L’illusion de l’amélioration des performances

A l’occasion d’une mise à jour (imposée) du système d’exploitation d’un serveur utilisé dans un contexte de travail réel, il a été nécessaire d’adapter les accès à la base de données en langage “orienté objet”. La préparation de ces adaptations a été faite sur un serveur plus récent dont les performances sont objectivement meilleures. Un gain de temps pour les tests était naturellement espéré. Et bien, non : c’est plus lent.

En comparant les temps de traitement de l’extraction la plus complexe de l’application portée entre le serveur de développement installé avec la “vieille version” et le nouveau, plus performant, installé avec la nouvelle version, tous les autres aspects restants identiques par ailleurs on constate une augmentation de ces temps de traitement de plus de 50 % !

Le syndrome de l’usine à gaz

En quoi cela consiste ?

Laissez un développeur s’attarder sur un sujet. Après en avoir résolu les fondamentaux, plutôt que de consolider et optimiser son code, il va s’attaquer aux fioritures (les petits plus au mieux superflus, voire inutiles ou même préjudiciables). Un jour son truc fini par devenir impossible à maintenir, même pas par son auteur original. Alors, celui qui se dévoue pour poursuivre jette tout et recommence (le cycle complet : une première solution simple et efficace, puis les fioritures, etc.).

On trouve un raffinement supplémentaire dans les options de commande en ligne et, encore mieux, dans les fichiers de configuration. Ah, ces fichiers de configuration, un régal !

Les exemples sont nombreux. Un des premier à qui on pourrait attribuer le syndrome de l’usine à gaz, c’est sendmail. Le type qui s’en est occupé a réussi à créer un langage de développement qui s’exprime dans les fichiers de configuration !

Et avec l’installation d’un nouveau serveur utilisé avec le système d’exploitation le plus récent, on observe une tendance qui se confirme : protéger son serveur des pirates est de plus en plus passionnant.

  • les processus de base changent et, surtout, ils deviennent de plus en plus diserts sur les journaux système,
  • cela en devient presque un travail d’IA de repérer les informations pertinentes pour la sécurité du serveur tellement elles sont noyées dans un flot d’informations inutiles,
  • la configuration par défaut des systèmes de protection est plus permissive,
  • l’organisation et la syntaxe de leurs fichiers de configuration est plus complexe et incompatible avec celles des versions précédentes.

Le must, c’est de voir que les regex sont encore plus illisibles qu’avant ; on n’aurait pas cru que ce serait possible !

Ah oui, on apprécie un détail croustillant : on ne trouve plus de vraie documentation…

Et dire que non seulement tous ces petits jeunes qui réinventent la roue donnent du boulot à tous les administrateurs mais en plus ils le font gratuitement !

 

Hôtel, location, copropriété : les différents types d’hébergement web

Si si, on parle bien d’hébergements “web” ici : de solutions pour profiter d’un espace de traitement et de stockage “en ligne” c’est à dire connecté à Internet.

Le clin d’œil aux différents types d’hébergement au sens plus classique est à la fois une métaphore pour donner une indications imagée sur les particularités des choix possibles et aussi parce que leur équivalents techniques (mutualisés, virtuels, dédiés) sont nettement moins lisibles.

Hébergement mutualisé (l’hôtel)

Un hébergement mutualisé, c’est comme une chambre d’hôtel : on s’occupe de tout à votre place en contrepartie d’une liberté et d’une confidentialité limitées. Et il y a aussi plusieurs niveaux de conforts (et de prix).

Les principaux inconvénients d’un hébergement mutualisé sont d’avoir des choix techniques imposés et un accès limité aux systèmes sous-jacents. La première limite est à considérer lorsque l’on choisit l’hébergement pour s’assurer que ses caractéristiques sont compatibles avec les configurations minimales exigées pour ce que l’on souhaite en faire. La deuxième limite apparaît en cas de problème, lorsque les possibilités et moyens d’investigations font défaut ou lorsqu’on veut déménager.

Le deuxième inconvénient d’un hébergement mutualisé est le risque de “voisins bruyants” et là les termes techniques et classiques coïncident. En effet, les ressources (processeur, mémoire, disque, réseau) sont partagées entre plusieurs utilisateurs. Si l’un d’entre eux se met à faire des traitements lourds avec des accès aux disques fréquents et d’importants échanges par le réseau alors tous les autres voient les performances de leur hébergement fortement dégradées. Bien sûr il y a des limitations mais elles ne suffisent pas toujours à prévenir les abus.

Pour ce qui concerne la confidentialité d’un hébergement mutualisé, c’est simple : elle est tout à fait correcte entre utilisateurs et nulle vis à vis de l’hébergeur.

Un hébergement mutualisé présente quand même un avantage considérable : tous les aspects techniques sont pris en charge par l’hébergeur : installation, configuration, sauvegardes, surveillance et dépannages.

Le serveur dédié (la copropriété)

A l’opposé de l’hébergement mutualisé, le serveur dédié offre les libertés maximales autant pour les choix techniques que pour les accès au système. On dispose d’un ordinateur pour soi tout seul et on peut en faire ce que l’on veut. La contre partie évidente est qu’il faut tout faire soi-même et tout assumer.

Il y a quand même des “parties communes” d’où l’analogie avec la copropriété dont notamment la connexion en réseau avec Internet et le “data centre” (bâtiment, alimentation électrique, …) qui reste toujours sous le contrôle et la maîtrise du fournisseur de même que les interventions physiques sur la machine comme par exemple un changement de disque, de mémoire ou d’autres composants de l’ordinateur.

Par contre la confidentialité est maximale. Elle n’est cependant pas totale puisque l’hébergeur dispose d’un accès physique à la machine : une petite panne fortuite et hop on en profite pour faire une copie du disque. L’interruption sera visible pour le propriétaire du serveur dédié mais pas ce qui s’est passé pendant l’anesthésie générale.

Le serveur virtuel (la location)

C’est une solution mixte des deux précédentes. On dispose des mêmes avantages (et contraintes) que celle d’un serveur dédié mais celui-ci est en réalité une fraction partagée d’un serveur dédié.

On retrouve les inconvénients d’un hébergement mutualisé : les conséquences potentielles de “voisins bruyants” et une confidentialité limitée, les espaces de stockage étant librement (et discrètement) accessibles à l’administrateur de la machine. En revanche, si les pannes matérielles peuvent toujours avoir des conséquences néfastes, elles sont gérées par l’hébergeur.

Lequel choisir ?

Le choix entre un hébergement mutualisé, un serveur virtuel ou dédié est d’abord une question de compétences plus qu’une question de prix. Il faut disposer des compétences d’un informaticien professionnel pour être capable de gérer un serveur dédié ou virtuel. Donc pour celui qui ne les a pas, le choix est vite fait.

Ensuite c’est une question d’exigence : si l’on recherche une confidentialité maximale, par exemple pour la gestion de données personnelles sensibles, il est de loin préférable de choisir un serveur dédié, quitte à devoir s’appuyer sur les compétences d’un prestataire professionnel de l’informatique. Ce qui reste intéressant dans tous les cas.