Aide
Commencer un sujet
Ajouter une réponse
Posté 26 mai 2006 - 10:31
Mettons tout de suite les choses au point, les techniciens pressés peuvent se rendre directement au chapitre Partir gagnant, mais j’ai l’intime conviction qu’ils regretteront un jour de n’avoir pas tout lu.
Au sommaire,
- Un peu d’histoire
- L’arrivée de l’ordinateur
- Le temps réel
- Les bases de données
- Les dispositifs de verrouillage
- Partir gagnant
- Mais quel intérêt pour mon site ?
Dans l’antiquité, enfin je veux dire jusqu’au milieu du siècle dernier… pour des raisons légales, réglementaires ou pratiques, une entreprise se devait de garder trace (l’obligation de la preuve), des tractations avec chacun de ses clients, auquel elle ouvrait donc un dossier. Oui, une chemise cartonnée, avec une sangle ou un rabat, selon les habitudes de la maison, éventuellement structurée en sous-chemises de couleur.
Lors de chaque acte de gestion, que ce soit à l’initiative du client (changement d’adresse, de RIB) ou à l’occasion d’un renouvellement, le gestionnaire demandait au service Archives de lui sortir le dossier, au vu duquel il appréciait le travail à exécuter, dont il laissait une trace circonstanciée dans ce même dossier qu’il retournait ensuite à l’archiviste.
Si par hasard un autre événement survenait pendant ce traitement, et était pris en charge par un autre gestionnaire, l’archiviste sollicité répondait que le dossier était en mains, et notre second gestionnaire mettait son événement sous le coude en attendant un moment plus propice.
Du point de vue du dossier, il était mis en file d’attente, comme au guichet de la Sécu : un seul intervenant à la fois !
L’arrivée de l’ordinateur
Les années 60 ont vu se répandre un nouvel outil de gestion, qu’on appelait ordinateur. Le travail du gestionnaire en a été considérablement modifié !
En effet, outre le problème à dénouer en demandant le dossier pour le consulter, le mettre à jour et le restituer aux Archives, il s’est vu attribuer la tâche supplémentaire de remplir un bordereau de saisie (plein de petites cases, n’écrire qu’un caractère par case, et tout en majuscules SVP), destiné à mettre à jour le dossier informatique du client, progrès oblige !
Le bordereau était ensuite confié à une encodeuse (souvent de jolies filles, si si, qu’on appelait aussi perfos), qui tapotait alors un clavier produisant des confettis en trouant des petits rectangles cartonnés fort justement surnommés cartes perforées. Les paquets de cartes étaient ensuite avalés par l’ordinateur, qui savait lire les trous pour effectuer une mise à jour circonstanciée du dossier informatisé du client.
Chaque nuit, l’ordinateur ruminait tous ces trous qu’on lui avait fait ingurgiter et, le matin, notre gestionnaire, comme tous ses collègues, recevait la liste (le listing) de toutes les fautes qu’il avait commises la veille (on dit des anomalies).
C’était du temps des Trente Glorieuses, on assurait le plein emploi...
Pour les mises à jour concurrentes, pas de souci. La machine ne mangeait qu’une carte perforée à la fois, et l’informaticien, qui avait eu à expliquer à l’engin comment digérer les trous sans faire d’aérophagie, lui avait également enseigné à retrouver le dossier concerné plusieurs fois par nuit s’il le fallait, mais ce n’était jamais en même temps : même une machine n’a que deux bras !
Le temps réel
Avec les années 70, nous sortons presque de la préhistoire, quoique... beaucoup d’entre nous n’étaient pas encore nés.
Les traitements différés de la décennie précédente (qu’on appelle aussi batchs) vont connaître de la concurrence. Progrès oblige, les ordinateurs deviennent de plus en plus intelligents et rapides. Ils fonctionnent tellement vite qu’ils donnent même l’impression de faire plusieurs choses à la fois.
On a en tout cas demandé à notre gestionnaire de libérer un peu de place sur son bureau, pour y installer un écran et un clavier. Pas trop content, notre gestionnaire. Plus de place pour travailler. On me prend pour une secrétaire. Etc.
La nouvelle procédure lui indique qu’il n’aura plus à remplir de bordereau, puisqu’on lui a préparé à l’écran un formulaire similaire (mais pas vraiment présenté pareil, ce serait trop facile), qu’il pourra directement remplir à l’aide du clavier.
Ce qui est agaçant, se dit le gestionnaire, c’est que je me fais rappeler à l’ordre à chaque fois que je commets une erreur. Mais, ajoute-t-il en son for intérieur, ce qui est sympathique, c’est que je la corrige tout de suite et qu’on n’en parlera plus demain (que tu crois !).
C’est ce que l’on a baptisé temps réel, ou TP (temps partagé), par opposition aux travaux différés.
On a fait un petit pas vers le zéro papier. Mais justement, pour le dossier papier… eh bien, le monde a changé. Enfin, un peu ! Il reste l’obligation légale ou réglementaire de la preuve tangible, physique, papier, quoi. Mais notre gestionnaire peut voir le dossier informatique, et n’a donc plus besoin du dossier papier pour étudier et traiter la requête du client. Il ne va donc plus le demander aux archives. Néanmoins, une fois sa transaction effectuée, il enverra la nouvelle pièce aux archivistes, pour insertion dans le dossier.
Les bases de données
Et puis, les systèmes de gestion de fichiers informatiques se font de plus en plus sophistiqués. On voit apparaître des bases de données, où l’on peut décrire le dossier comme un vrai dossier, avec ses chemises et sous-chemises, au lieu de l’alignement informe d’un fichier séquentiel qui s’enroule sur une bande magnétique (mais sans musique)… De plus, au lieu d’alimenter cette base la nuit, on permet au gestionnaire d’y inscrire directement sa mise à jour le jour.
Et c’est là qu’apparaît le danger, de l’avis de l’informaticien, qui s’estime garant de l’intégrité des données. Il craint en particulier l’erreur de programme non détectée, qui va laisser des dizaines de gestionnaires polluer à tour de bras la base à l’insu de leur plein gré.
Il craint aussi le télescopage de mises à jour réalisées par plusieurs gestionnaires dans un même dossier. Par exemple, un changement d’adresse et un changement de RIB, qui relèvent de deux services distincts.
Le cas d’école est simple à expliquer en trois phases,
- nos deux gestionnaires chargent en mémoire le même dossier de M. Martin, habitant à l’adresse A et ayant un compte dans la banque R,
- le premier remplace l’adresse A par B, et valide sa mise à jour,
- le second, interrompu par un coup de téléphone, tarde un peu, puis indique que la banque T remplace la banque R, et valide sa mise à jour.
- lecture pour les deux, adresse A et banque R,
- écriture (du premier), adresse B et banque R,
- écriture (du second), adresse A et banque T.
Il est des informaticiens qui, eux, n’ont pas oublié d’être intelligents. Et qui proposent des solutions fondées sur le verrouillage du dossier. Eh oui, dans le temps, le dossier papier n’avait pas le don d’ubiquité, un seul gestionnaire à la fois !
Pour cela,
- à l’arrivée du premier gestionnaire, lecture du dossier, positionnement d’un drapeau occupé, réécriture immédiate, envoi de son image au gestionnaire (adresse A, banque R),
- à l’arrivée du second, lecture du dossier, zut il est occupé, fin de non recevoir « ce dossier est en mains, repassez plus tard »,
- à la validation de la transaction du premier, réécriture du dossier modifié, positionnement du drapeau libre, confirmation de la mise à jour au gestionnaire (adresse B, banque R),
- lorsque le second gestionnaire tente à nouveau sa chance, le dossier lui est délivré (adresse B, banque R), il peut indiquer la banque T, valider, et le dossier contiendra bien en final (adresse B, banque T). CQFD.
Notre gestionnaire ronge son frein, proférant des propos bien sentis à l’encontre du progrès, de l’informatique et des informaticiens ! L’ordinateur, lui, reprend son souffle. Les exploitants (ceux qui mettent le charbon dans la chaudière), utilisent le système de sécurité de la base de données pour la rétablir dans son état juste avant le crash. Et ils annoncent triomphalement que c’est reparti, avec le sentiment d’avoir vite et bien fait leur boulot !
Notre gestionnaire, de retour de déjeuner (il faut bien reprendre des forces), constate que « ça marche ! » et se précipite comme un forcené sur son clavier, pour constater que « ce dossier est en mains, repassez plus tard ». C’est pas vrai, ça ! Et en plus, il y en a un qui m’a pris mon tour. Déconfit, il met un post it sur le dossier et s’attaque au suivant.
Le lendemain matin, « ce dossier est en mains, repassez plus tard » ! Pas possible ! Encore la faute à l’informatique !
Eh oui, en fait, la veille, avant le plantage, le dossier avait été positionné occupé. Le dialogue ayant été interrompu, personne ne peut plus le libérer, il reste sur une voie de garage…
Bien entendu notre informaticien, agacé par toutes les demandes de passage de gomme à octets pour repositionner des drapeaux à libre, réfléchit à la conception d’une parade. On peut en citer deux,
- on installe le drapeau occupé non pas dans le dossier, mais dans un fichier spécialement prévu à cet effet. Une fois la transaction terminée, le drapeau sera effacé dans ce fichier. En cas de crash, il suffit de vider ce fichier avant de redémarrer,
- on conserve le principe du drapeau inscrit dans la base, mais on lui adjoint une identification du gestionnaire qui a pris le dossier en charge (souvent, on choisit le numéro de terminal, identifiant unique pour la machine, un peu comme l’adresse IP aujourd’hui). Lorsque le gestionnaire revient après plantage, on le reconnaît et on le laisse reprendre sa mise à jour. Il reste le problème d’une panne du terminal (eh oui, tout est possible, tout est réalisable !), où le gestionnaire, obligé d’aller se brancher ailleurs, ne sera pas reconnu pour ce dossier, et refoulé !
Les dispositifs de verrouillage
On a donc demandé aux concepteurs de SGBD (systèmes de gestion de bases de données) des dispositifs logiques de verrouillage, déchargeant le développeur de ce type de contraintes. Il lui suffira d’annoncer qu’il effectue une lecture avec intention de mise à jour, et la ressource concernée lui sera réservée jusqu’à l’accomplissement de cette mise à jour.
Dans le cadre d’un SGBDR (relationnel), il est ainsi possible de locker (verrouiller) une table, ou un rang (entendez par là un fichier, un enregistrement).
Le problème, c’est l’utilisateur qui se présente en intention de mise à jour, provoque le verrouillage d’une table, et s’interrompt pour une raison [peut-être] tout à fait légitime et indépendante de sa volonté. Pendant qu’il fait autre chose, personne ne peut plus travailler avec cette table. Si elle est stratégique, à la croisée de tout le système, toute l’entreprise sera arrêtée par un amateur de café qui va s’en chercher un !
J’ai bien entendu outré le propos, mais on n’est pas à l’abri de certaines contentions de données, qu’il faudra diagnostiquer et tenter de résoudre au cas par cas, le plus souvent à chaud.
Entre temps, notre gestionnaire doit toujours penser à envoyer aux archives tous les compléments de dossier qui sont passés entre ses mains : le dossier papier reste de rigueur dans la plupart des domaines officiels.
C’est ainsi que j’ai pu, dans une Caisse de Retraite, voir se fermer le plus vieux dossier de la maison. Il était effectivement un brin poussiéreux. Pourtant, le document du dessus était encore tout chaud : c’était l’acte de décès d’une centenaire, qui mettait un terme à une longue réversion : elle avait épousé à 20 ans un vieillard de 80 ans. Le dossier qu’on refermait avait été ouvert 140 ans auparavant !
Partir gagnant
Pour éviter les problèmes de blocage logique résultant d’une sécurisation concurrentielle des données, il existe une méthode que j’appelle « Partir gagnant ».
Elle consiste à prétendre qu’il n’y a vraiment pratiquement aucune chance que deux gestionnaires attaquent en même temps le même dossier. On va donc ignorer ce risque et oublier toute prudence. Dans notre exemple, deux gestionnaires demandent en même temps le même dossier. On le leur fournit. Pas de problème, puisque ça n’arrive jamais.
Le premier, un bosseur qui ne mélange pas le travail et le plaisir, effectue son changement d’adresse avec brio et valide sa mise à jour. Le second, interrompu par sa femme au téléphone (une sombre histoire de crèche et de gamin malade), est un peu perturbé, on le comprend. Mais il prend sur lui, réalise son changement de banque et valide sa mise à jour. Et là, surprise ! « Désolé, quelqu’un a mis à jour ce dossier, veuillez reprendre la procédure ».
Un miracle ? Non. D’ailleurs, en informatique, les miracles n’existent pas, je l’affirme, c’est du vécu ! En fait, on a demandé à chaque programme chargé d’une mise à jour,
- de conserver soigneusement une image du dossier tel que fourni à la lecture, en parallèle avec son état en cours de mise à jour,
- au moment de la demande de mise à jour de la base, de relire le dossier pour vérifier qu’il est resté strictement identique à son état initial en début de transaction,
- si oui (c’était bien le cas pour le premier gestionnaire), d’entériner la mise à jour demandée,
- sinon (c’est le cas du second gestionnaire), de la refuser en émettant le message d’excuses.
Certes, si l’on compte bien, on réalise deux lectures et une écriture. Mais il faut bien comprendre que la lecture initiale est libre, c’est-à-dire sans intention de mise à jour, laissant toute latitude au consommateur de café sans pénaliser ses collègues. Par ailleurs, il n’y a pas de dialogue, donc d’interruption humaine, entre la seconde lecture, avec intention de mise à jour, et l’écriture, donc l’ensemble se déroule en une infime fraction de seconde.
Il faut savoir aussi que, à cause de cas de navigation complexe dans les données au cours de la transaction, plusieurs SGBD demandent systématiquement une relecture de positionnement avant mise à jour. Cette dépense obligatoire ne peut donc plus être jugée inconsidérée…
Eh bien, en 10 ans d’expérience de cette méthode appliquée à l’ensemble de l’informatique dédiée à 500 utilisateurs gérant 3 millions de dossiers, l’incident a été relevé… une fois ! Et le plus surpris a été le chef de projet informatique, qui avait depuis longtemps désespéré qu’on lui annonce le cas.
Etonnante aussi, la réaction du gestionnaire qui a vu apparaître le message : il a trouvé la chose tout à fait normale, et sécurisante. Il a en outre deviné quel collègue l’avait doublé, et est passé le voir pour discuter du dossier !
Mais quel intérêt pour mon site ?
Si vous avez conçu un site purement descriptif, fonctionnant uniquement en consultation, il est certain que cet article ne vous concerne pas… mais ne m’en veuillez pas, vous auriez pu vous en douter au regard de son titre !
Si en revanche votre site collecte des données, il serait peut-être dommage d’en perdre certaines (par exemple, dans l’incrémentation de compteurs à l’occasion d’un sondage) du fait d’une affluence par ailleurs plutôt flatteuse !
A bon entendeur…
Ce message a été modifié par dylav - 30 mai 2006 - 09:45 .
Multi-citation
?
pour le sujet et surtout le contenu 
(si .sujet!=.contenu) et :ciao:E.O.T : à vous lire.
Posté 09 mars 2010 - 12:56
:"Si vous êtes manageur chez Orange/France telecom et que vous souhaitez pousser un ou une employée vers le vide merci BEAUCOUP de leur asséner régulièrement: "J'avoue ne pas bien saisir le sens de ton intervention, ni son rapport avec le sujet." ; ensuite trouvez et utilisez tout les moyens pour l'exclure et lui faire sentir que cette personne est inutile. Un ou une employée plus conciliante pour son salaire et terrorisé(e) par le chômage donc plus malléable pourra ensuite prendre ça place." 
:HS
