Au Pied Levé - À Main Levée
I-1.2. Développer À Main Levée
par , 01/04/2020 à 11h45 (397 Affichages)
■ Concept « ask and use »APL-AML est une monographie fragmentée en plusieurs billets pour des raisons de volume.
Un billet SYNOPSIS et un billet SOMMAIRE agrègent tous les billets du blog via des liens hypertextes.
■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■
- Concept « ask and use »
- Idéation
- Programmation mentale
- Structurer l’inconnu
- Écouter son intuition plutôt que sa logique analytique
- Développer chaque fonctionnalité « juste-à-temps »
- Modélisation des données
- Qu’est-ce qu’un modèle ?
- Modèle entités-relations
- Gestion de la BDD
- Règle de la littérature administrative
- Discussion « Modélisation des tables et des vues »
- Des gestionnaires chefs de projet et un développeur traducteur
- Informatiser les processus annexes
- Implémenter l’existant
- Assurer la veille technologique
« Une photo tout de suite ! » C'est ce à quoi aspirait Edwin LAN en inventant le Polaroïd, appareil photo à développement instantané. Pourquoi attendre s’interrogeait-il ?
« Une application tout de suite ! » C’est le concept « ask and use » (demandez puis utilisez). C'est le développement instantané… d’application. Pourquoi attendre ?
Le concept « ask and use » peut être perçu comme étant au soft ce que la technologie « Plug and Play » est au hard ou au « temps réel » ce que le développement classique, analytique serait au « batch ». Aucun délai, que de la production logicielle immédiatement opérationnelle.
Certains aspects de la problématique ne pouvant être absorbés lors du premier cycle de gestion, sont pris en compte à l'occasion d'un cycle ultérieur. Quelques cycles suffisent généralement pour stabiliser un applicatif de gestion de type départemental.
La formule « ask and use », plus percutante en anglais, symbolise autant qu'elle traduit le concept fort d'un développement d'applicatif s'appuyant sur des valeurs comme le pragmatisme, le savoir-faire, le bon sens, l'autonomie, l'engagement, le risque, pour offrir à l'utilisateur final l'outil informatique qu'il attend avec une réactivité quasi immédiate. Mais dans les faits, la démarche « bottom-up » dépouillée, qui s'oppose à la déontologique démarche « top-down » rigoureusement balisée, s'inscrit difficilement dans notre structure mentale, dans nos structures organisationnelles hiérarchisées, compartimentées, corsetées. Certains l’assimilent à tort à de la « perruque » (développement sauvage) alors qu'elle constitue un challenge, une solution adhocratique consentie, assumée et réalisée en toute transparence.
Le développement s'effectue au fur et à mesure des besoins exprimés par les gestionnaires tout au long d'un cycle de gestion. La démarche peut se résumer ainsi : ce que le gestionnaire veut, l'informaticien le fait. La satisfaction d'une demande, quasi instantanée, nécessite généralement entre l'heure et la journée, rarement au-delà. La production logicielle se réalise « in situ » et précède de peu les échéances du cycle de gestion.
■ Idéation
L'idéation est le processus créatif de production, développement, et communication de nouvelles idées ; le terme idée signifie ici un élément de base de la pensée, ou plutôt de la vie psychique en général, qui peut être aussi bien sensoriel ou concret qu'abstrait.
L'idéation comprend tous les stades d'un processus de pensée original, de l'innovation au développement de l'idée et jusqu'à son achèvement. C'est ainsi un aspect essentiel de tout processus créatif ou conceptuel, d'où son importance aussi bien en pédagogie que dans la vie pratique. Le terme idéation est un anglicisme tiré de ideation, terme inventé par John Stuart Mill.
En APL-AML, nul besoin de Modèle Conceptuel des Données, pas plus que de Modèle Conceptuel des Traitements. Données et Traitements s’appréhendent ensemble, fonctionnalité par fonctionnalité, chacune s’inscrivant dans un projet d’informatisation en construction. Il n’y a pas de distanciation entre le développeur et la problématique à informatiser. Le développeur s’appoprie conceptuellement la problématique et met en œuvre instantanément ce qu’il est en train de concevoir mentalement.
Informatiser une problématique dans l’urgence en trois jours voire en une journée, sans cahier des charges, bien sûr personne n’y croit… et pourtant, ça marche ! Le cahier des charges n’est pas papier, il est vivant, ce sont les gestionnaires. Pas besoin de « users stories » . La démarche se résume en un mot : l’]idéation.
Quand on développe à main levée, on ne sait pas de quoi le lendemain sera fait. C’est en quelque sorte la création d’une œuvre progressant au rythme d’une réflexion personnelle qui s’adapte au vécu quotidien de l’entité métier. Le développement doit être aussi épuré, créatif et sûr que le trait de pinceau de l’artiste peintre. Le développeur étale le bitume juste devant le rouleau compresseur que sont les gestionnaires ; pas de retour en arrière possible, il faut décider vite, sans se tromper, avec lucidité.
Le développeur vit in situ la réalité de la problématique et n’a donc pas besoin de la modéliser pour l’informatiser. Il lui suffit de regarder, d’écouter… de savoir parler à l’oreille des gestionnaires. Les fonctionnalités à développer sont évidentes puisqu’il s’agit de satisfaire les besoins immédiats et toutes les informations nécessaires sont accessibles, circulent, vivent dans l’entité métier. Il n’est même pas nécessaire de poser des questions. La plupart du temps, les gestionnaires sont des femmes, elles ont mille choses à assumer dans leur journée de mère de famille. Pour assumer leur travail au quotidien, elles savent s’organiser, optimiser leurs tâches. Il y a beaucoup de non-dits dans leur activité et bien souvent, elles ne savent pas qu’elles savent.
Anecdote
Le concept d’idéation se situe entre le concept de brainwriting et le concept de mémorandum. Selon le niveau que l’on considère, l’idéation est à l’application ou à ses processus, ce que la programmation mentale est à la fonctionnalité (écran, programme ou requête sql).
Il n’y a pas de distanciation entre la problématique à informatiser et le développeur. Le développeur s’appoprie conceptuellement la problématique et met en œuvre instantanément ce qu’il est en train de concevoir mentalement.
■ Programmation mentale
À l’instar du calcul mental, la programmation mentale est une aptitude qui se travaille, qui active des zones temporales préfrontales du cerveau, généralement impliquées dans la mémoire à long terme et plus particulièrement dans la mémoire procédurale.
Pour progresser, il faut s’entrainer, penser pratique, mettre en place diverses stratégies pour que les choses deviennent naturelles. Cette gymnastique de l’esprit prend réellement corps à mesure que l’on pratique. Le cerveau développe avec la répétition, des raccourcis logiques qui permettent de développer bien plus rapidement. La répétition permet d’intérioriser chacun des processus et cela se limite pas à la programmation mais concerne le développement dans sa globalité. « Développer » n’est pas seulement « programmer », c’est être capable d’informatiser et pas uniquement d’écrire un programme. Cela demande du temps, de l’investissement personnel mais on conserve ses réflexes toute sa vie.
Un Billet « Programmation mentale » développe le sujet dans le chapitre consacré aux bonnes pratiques de développement.
■ Développer chaque fonctionnalité « juste-à-temps »
Processus : c’est ce que l’on appelait autrefois « une chaine de traitement » et que l’on peut définir comme une unité logique de traitement.
C’est la chronologie des étapes du cycle de gestion qui rythme l’informatisation du processus principal.
Fonctionnalités : Ce sont les besoins informatisés sous forme d’écrans et le plus souvent d’éditions, de requêtes SQL, parfois un mixte des deux.
Le développeur travaille tel un écrivain public et ce sont finalement les gestionnaires eux-mêmes qui modélisent l'applicatif. Entre développeur et gestionnaires, le feed-back est permanent et immédiat. Une incompréhension n'a jamais de conséquences car elle se résout aussitôt. La pression exercée par les échéances du cycle de gestion rend les développements nécessairement efficaces, utiles, sobres, conviviaux. Conviviaux pour rendre les gestionnaires totalement autonomes dans leurs prérogatives et permettre ainsi au développeur de poursuivre ses investissements sans perdre de temps en assistance.
Développer en « écrivain public », ne s'improvise tout de même pas, cela suppose d'être au clair avec les principales méthodologies d'analyse et de programmation, ou en plus imagé, d'être câblé dans sa tête. Il ne s'agit pas de perdre son temps à phosphorer sur un MCD hirsute, un MCT indigeste, ou à produire des arbres programmatiques de PS sans intérêt (PS = Programmation Sauvage. Non ? ). Il ne s'agit pas non plus de développer en se réinventant chaque matin.
Pendant que les gestionnaires saisissent la demande, le développeur programme les premières fonctionnalités qui vont être rapidement utilisées. C’est tout simplement l’application du principe RAD :
« Les concepts de qualité permanente et de livraison permanente sont rendu possibles par la réalisation dès le début du prototypage d'une application techniquement fiable que l'on incrémente de fonctionnalités tout en préservant cette fiabilité. »
Ce sont les besoins des gestionnaires qui imposent le développement et la mise en exploitation des fonctionnalités. Ce mode de fonctionnement respecte cet autre principe RAD :
« Rien n'oblige à tout réaliser d'un seul tenant. L'amélioration continue et incrémentale est le principe fondamental du RAD, en totale opposition avec les méthodes classiques qui se caractérisent par une approche monolithique des problèmes. »
Rien n’oblige à tout réaliser d’un seul tenant car les gestionnaires n’utilisent les fonctionnalités qu’au fur et à mesure de leurs besoins, lesquels se manifestent au fil du cycle de gestion.
■ Structurer l'inconnu
L’existence même d’une entité métier se justifie par la nécessité de gérer une problématique de gestion spécifique, laquelle constitue son cœur de métier, son fonds de commerce ou son « objet social ». Informatiquement, c’est le « processus principal » qui met en œuvre une succession de traitements au cours de son cycle de gestion.
À ce processus principal sont la plupart du temps associées des « processus périphériques, annexes » ayant eux-mêmes leur propre cycle de gestion.
APL-AML ne s’intéresse dans un premier temps qu’au processus principal. Ses traitements se succédant chronologiquement, les développements se réalisent au fur et à mesure des besoins.
Il s’agit de traiter vite n’importe quel problème avec une vue d’ensemble. Il faut tout voir, tout sentir à la fois et tout faire à l’instant juste. La somme d’informations à traiter simultanément est importante et il y a forcément le risque de se laisser déborder jusqu'à perdre pied. C’est une gestion de crise permanente mais plus tard, il restera le souvenir d’un instant de grâce qui semblera avoir duré une éternité, tant il était plus dense que n’importe quel moment de la vie ordinaire.
« La plupart des procédures traditionnelles de management encensent la structure et la prévisibilité. La difficulté dans un contexte ad hoc consiste à donner un semblant d'organisation à ce qui est apparemment inconnu. On y parvient par une planification à court terme assez précise, mais très lâche pour les étapes ultérieures. Dans ce type de projets, une trop grande partie des objectifs à moyen et long terme dépend de ce qui a été mis à jour à court terme. »
Ce principe de l’adhocratie appliqué au développement, signifie prévoir dans le menu des applications, les traitements qui ne seront développés que le moment venu, selon l'urgence, la disponibilité et l’imagination du développeur. Les américains disent "just in time". Le développeur sophistique ce menu parallèlement à ses investissements. Certains items ne sont pas encore opérationnels mais constituent pour le développeur ses prochains objectifs à court terme et aident les gestionnaires à intégrer mentalement leurs prochaines fonctionnalités disponibles tout en leur donnant l’illusion que l’application existe vraiment. Trop sollicité(e)s par leur quotidien, les gestionnaires tentent rarement de tester ces items pas encore opérationnels.
Le système de menus de l’application devient la colonne vertébrale et le sommaire des développements. Les premières fonctionnalités sont rendus accessibles aux gestionnaires via les items de leur menu.
NB : Deux systèmes de menus sont proposés dans les billets « Annexes ».
■ Écouter son intuition plutôt que sa logique analytique
Les gestionnaires doivent penser que leur application a toujours existé ; en fait, le développement se réalise au fur et à mesure, au rythme de leur cycle de gestion, en anticipant leurs besoins juste ce qui est nécessaire. C’est passionnant, euphorisant. Le cerveau aime qu’on le sollicite dans la précipitation, il y a un plaisir beaucoup plus important à écouter son intuition que le plaisir à écouter sa logique analytique.
Développer à main levée sollicite l’imagination, attise l’esprit créatif. Il ne s’agit pas comme dans une démarche top-down de modéliser rationnellement, d’un côté les données, de l’autre les traitements, pour ensuite développer selon une démarche procédurale convenue, mais de visualiser, de concevoir mentalement, tout en réalisant dans l’instant… de créer finalement. La réflexion est créative, constructive et non déductive, assistée. Elle s’inspire du besoin, lequel détermine les données qui lui sont nécessaires. Traitement et Données sont intimement liés. Cette démarche n’implique pas pour autant ignorer la démarche classique mais ce n’est pas cette dernière qui impose son tempo, elle veille seulement en arrière plan, en tâche de fond dans le subconscient du développeur.
Bien sûr que le développeur connait la plupart des méthodes de développement, sait concevoir un modèle des données, un modèle des traitements, cela fait partie de sa culture, mais confronté à l’urgence de satisfaire le besoin de l’utilisateur, l’heure n’est pas à modéliser, à virtualiser la perception informaticienne d’une problématique dans sa globalité mais bien à réaliser concrètement l’outil dont a besoin l’utilisateur dans les jours, les heures voire les minutes qui suivent. Il n’est plus question de modèles, d’entités, d’attributs, d’identifiants, il est question de tables, de données et d’index. Besoin oblige, les relations entre les tables s’imposent d’elles-mêmes. La forme normale des relations, c’est la réflexion qui passe directement de l’objet du monde on ne peut plus réel à la BDD. Les événements qui coordonnent le déclenchement d’une opération ?... C’est le besoin crucial de l’utilisateur qui s’exprime le plus souvent dans un climat de tension.
La méthode de travail s’appuie sur un package « autonomie » comprenant créativité, prise de risques, responsabilités, professionnalisme, exigence, rigueur, programmation mentale, empathie cognitive… et non sur le package rassurant des méthodes classiques.
Le développement « juste-à-temps », constitue une sorte de garde-fou qui impulse, qui inspire, qui suscite les meilleurs choix, les meilleures décisions. Confronté au danger, l’instinct de survie oblige à être pertinent, stimule l’imagination pour toujours créer, inventer la meilleure solution. Dans un contexte « juste-à-temps », non seulement on n’a pas le droit à l’erreur, mais on n’investit qu’utile.
On n’est pas obligé de succomber au « toujours plus de technicité » qui crée des besoins inutiles. L’important, c’est que l’application fasse ce que demandent les gestionnaires qui se fichent bien que leurs écrans clignotent ou soient couleur pastel. La sophistication à rechercher n’est pas dans la technicité informaticienne mais dans la procédure administrative, la convivialité des interfaces écrans et états. Et cela demande des compétences non pas en techniques informatiques mais en communication, en organisation, en simplification des procédures… en simplification du développement lui-même, ce qui impacte le choix de ses outils de développement.
■ Qu’est-ce qu’un modèle ?
« Un modèle, c’est la représentation d’un système par un autre, plus facile à appréhender. C’est la transposition d’un monde qui nous est étranger dans le monde que l’on connait, de telle sorte qu’il soit possible d’en simuler mentalement le fonctionnement avec nos mots et avec nos règles. C’est un aboutissement provisoire dans la construction de la connaissance qui doit servir de référence à la reproduction. »
Un modèle (Pourquoi modéliser ?) est donc un langage commun, précis, connu de tous les développeurs. Vecteur privilégié de communication, c’est avant tout une représentation abstraite du monde réel qui sert :
- à communiquer et échanger des points de vue afin d'avoir une compréhension commune et précise d'une problématique,
- à appréhender l’ensemble d’une problématique,
- à fournir une documentation suffisante à l’équipe de maintenance,
- à assurer l'homogénéité de cette documentation entre plusieurs projets pour faciliter les passages d'un projet à un autre.
Les outils actuels savent maintenant exploiter ces modèles pour faire de la génération de code, voire des allers-retours entre le code et le modèle, sans perte d'information.
Certaines initiatives ont une petite tendance à « détourner » la vraie modélisation en proposant des outils de modélisation un peu trop proches du code, notamment en prévoyant les types de données dès le MCD.
Le modèle ne joue plus alors son rôle de représentation abstraite, mais devient un outil de création et de gestion de la BDD.
■ Modèle entités-relations
Pour APL-AML, la modélisation des données reste classique et s'appuie sur le formalisme entité-relation (principe RAD) sans qu’il soit envisageable de construire à priori une représentation graphique symbolisée du MCD (intégrale ou même partielle).
Lorsque la démarche est ascendante, le développement se réalise dans l’urgence. Une vision exhaustive de la problématique n’est pas l’objectif. Il s’agit de développer chaque fonctionnalité au pied levé, à main levée, donc de créer des tables et en implémenter d’autres dans l’instant.
Au final, si une BDD est constituée de 200 tables on ne les manipule jamais toutes en même temps. Une trentaine, c’est déjà conséquent et tout-à-fait maitrisable car la majorité des tables sont des tables de référence.
Visualiser mentalement les entités interagissant dans une fonctionnalité suffit généralement à conceptualiser le besoin.
Exemple extrait d’un écran de M-à-J des interventions formateurs :
Cet écran-commentaire assimilable à un MCD succinct montre que le programme (2.422 lignes) ne compte que 5 tables-entités pour un total de 25 tables. Visualiser 5 tables-entités et 20 tables de références (+ 1 vue) n’a rien d’un exploit et ne constitue pas une charge mentale insurmontable. Encore faut-il avoir formaté son petit disque dur dans sa mémoire procédurale à long terme, de la même façon que pour pratiquer la programmation mentale.
■ Gestion de la BDD
En développant in situ, le développeur n’est qu’un traducteur des besoins exprimés par les utilisateurs-gestionnaires, lesquels sont autant de chefs de projets. Le développeur n’a pas besoin d’un MCD pour communiquer, ni pour valider ses développements. La communication est permanente et la validation est instantanée.
Lorsque l’on développe à main levée, on ne s’appuie pas sur sa mémoire immédiate mais sur sa mémoire procédurale. On doit s’organiser, s’inventer une codification, une normalisation, une charte graphique. On grave son savoir-faire dans sa mémoire procédurale à long terme. La démarche mentale se réalise naturellement, pilotée en tâche de fond par cette mémoire procédurale.
Utiliser l’EDI du SGBD Informix ESQL/C et gérer les SQL de création des BDD suffit. Ne pas gérer de MCD n’entrave d’aucune charge mentale, bien au contraire, on est libre, le cerveau reste totalement disponible. La création et la gestion des tables se réalisent conjointement via l’EDI du SGBD et les requêtes SQL de création des tables, lesquelles équivalent (mieux présentées) au DBSCHEMA du SGBD.
La maitrise de la BDD se réalise par la gestion de plusieurs SQL :
- - Création des tables (voir dans les Annexes, le Billet « Ex&Co Sql CREATE_BDD »)
- - Création des index (voir dans les Annexes, le Billet « Ex&Co Sql CREATE_IDX »)
- Création des views
- Création des synonymes
■ Règle de la littérature administrative
« Lorsque l’on a deux idées à exprimer, il est toujours préférable de faire deux phrases. »
Cette simple règle appliquée à une entité lors de la conception d’une BDD peut tout simplement justifier la création de deux tables plutôt qu’une seule.
Un exemple :
Concernant la BDD Examens-Concours, on peut ne percevoir qu’une seule entité « Personnes », laquelle interviendrait à la fois en tant que « Candidats » et « Membres du jury ».
Bien qu’il arrive que des Membres du jury soient également Candidats, la duplication de personnes s’avère le meilleur choix car à y regarder de plus près, on se rend compte que les attributs Candidats sont très différents des attributs Membres du jury. D’où le parallèle avec les deux phrases pour exprimer deux idées différentes.
Au niveau national, le choix a été différent, l’application Examens-Concours ne considère que ce qui concerne les « Candidats » et occulte complètement la partie « Jury » qui fait l’objet d’une application indépendante… que personne n’utilise.
Dans un autre domaine, celui de la Formation Continue, conceptuellement très proche des Examens-Concours, l’entité « Personnes » intervient à la fois en tant que « Stagiaires » et que « Formateurs ». Contrairement aux Examens-Concours, il n’y a pas lieu de créer deux tables car les attributs Stagiaires et Formateurs ne sont pas fondamentalement différents à l’exception des rares intervenants extérieurs et la table des personnes s’initialise en fait à partir de celle de la gestion du personnel.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45{ pec (personnes examens-concours) } create table pec ( n_pec serial not null, n_pim integer, num_can char(10), num_mtr char(10), exercice datetime year to year not null, numen char(13), civilite char(3) not null, nom_cec char(5) not null, nom_naiss char(20) not null, nom_usage char(20) not null, prenom char(20) not null, prenom_2eme char(20), d_naissance date, lieu_naissance char(30), adresse char(38), adresse_2 char(38), lieu_dit char(38), c_cp char(5), l_ld char(30), tel_dom char(20), tel_bur char(20), coordonnees_1 char(38), coordonnees_2 char(38), fonction char(30), sit_fam char(1), sit_mil char(1), sit_adm char(1), d_titulaire date, enfants char(2), cotorep char(1), c_os char(3), c_nationalite char(1), t_diplome char(1), l_diplome char(30), c_et char(8), t_et char(1), flag char(1) ) ; grant all on pec to public;
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31{ mj (membres du jury) } create table mj ( n_mj serial not null, numen char(13), civilite char(3) not null, nom char(20) not null, prenom char(20), adresse char(38), lieu_dit char(38), c_cp char(5), l_ld char(30), c_gr char(8), indice char(3), fonction char(30), memo char(30), mode_paiement char(2), se char(2), pb char(2), c_et char(8) not null, envoi char(1) not null, d_tj date, division char(30), tel_dom char(20), tel_bur char(20), e_mail char(38) ) ; grant all on mj to public;
■ Discussion « Modélisation des tables et des vues »
Développer en s’abstenant de créer un MCD est inconcevable pour la plupart des développeurs. Mais créer et gérer directement sa BDD revient finalement à ce que font ces outils de modélisation qui vont jusqu’à générer du code, jusqu’à créer et gérer une BDD. La réflexion du développeur est la même, qu’elle s’applique directement à la construction de la BDD, ou par l’intermédiaire d’un tel outil de modélisation. Dans le premier cas, le développeur est responsable, autonome, dans le second cas, il est assisté. Il n’y a donc pas matière à s’offusquer de ne pas créer de MCD.
Dans cette discussion, je faisais part de mon expérience personnelle de visualisation mentale des entités interagissant dans une fonctionnalité et voici les réactions virulentes qui s’en sont suivies :
Ma réponse :
- À quoi sert de faire une vue sur une seule table alors qu'on peut interroger directement la table ?
OK, ça peut être une question de droit d'utilisation (GRANT PRIVILEGE) mais à part ça, le seul intérêt éventuel que je vois et qui n'est pas le cas le plus fréquent, c'est de programmer des colonnes calculées (pourcentages, âge ou ancienneté...).
À moins qu'on doivent comprendre de votre discours sur le développement rapide sans modélisation que vous avez des tables indépendantes pour des concepts voisins et qu'ainsi, par exemple, une personne physique avec son nom et son prénom usuels et d'autres données la caractérisant soit présente dans la table des employés, des chefs de service, des membres du comité d'entreprise et que sais-je encore... Autrement dit que vous soyez un adepte de la redondance des données avec tous les risques que ça suppose en termes de cohérence de données...
- Tant que votre système fonctionne et que c'est vous qui le maîtrisez, tout va bien. Mais je ne voudrais pas avoir à intervenir sur votre BDD ! Rien que de voir que vous avez 205 tables pour un système de formation continue me laisse songeur…
- Faute de conceptualiser, c'est exactement le contraire qui se produit : à l'épreuve des faits (performances désastreuses, intégrité des données non vérifiées, règles de gestion hasardeuses), il faut revenir en arrière, casser pour reconstruire, ce qu'une conception soignée en amont aurait évité.
Je le constate malheureusement chez de très nombreux clients, dans différents corps de métier.
- En lisant tes arguments, je les mets en lien avec un lointain mauvais souvenir de projet horrible auquel je me suis confronté…
- Quelle source de charge mentale !
- Pour rester dans la métaphore du jeu d'échecs, considérez que le MCD, c'est à la fois l'échiquier et les règles de déplacement des différentes pièces.
S'il l'échiquier n'est pas conforme ou que les joueurs ne sont pas d'accord sur la façon de déplacer les pièces, la partie d'échecs sera compliquée, bancale voire... impossible !
- Penses-tu respecter les 3 premières formes normales incontournables ? Valeurs atomiques, non redondantes, rarement nulles.
- Avec la précision de ton récit, je comprends enfin le mode d'emploi, pour transformer une base relationnelle normalisée de 500 colonnes, en un gruyère de 4000 colonnes infestées de nulls, non atomiques et répétitives, à mettre constamment à jour !
- Fais-tu partie des casse-cou, qui ne comptent jamais sur leur MCD strictement écrit, avant de mettre en œuvre les nouvelles règles de gestion sur MLD ?
- Modifies-tu, bille en tête ton MPD, sans te confronter à ton MCD, de plus en plus confusément mentalisé ?
- Quelle source catastrophique de charge mentale !
- Quand tu ne travailles pas sur tes bases pendant un mois consécutif, as-tu encore en tête les moindres règles de gestion du MCD, et les cas d'utilisation de tes moindres développements ? À quel endroit mentalises-tu les moindres règles de gestion du MCD ?
- Es-tu coutumier de toujours oublier de laisser des spécifications derrière toi ?
- Es tu coutumier de toujours oublier de laisser des instructions de maintenance applicative derrière toi ?
- Te crois-tu capable de transmettre sereinement, qualitativement tes projets à un successeur ?
- Sais-tu travailler en équipe ?
- Quelle horreur !
- Ce qui ce concevrait mieux s'énoncerait clairement, et les mots pour le dire arriveraient aisément !
- Je comprends, entre les lignes, que tu assumes la construction d'une base de données, comme un travail nécessairement solitaire, sans cadre, éventuellement normalisé, éventuellement documenté.
- Je comprends également que tu assumes que l'analyste mentalise jour après jour, les règles de gestion du métier. (idéalement, mieux que les gestionnaires ?)
- En conséquence, son départ signe l'arrêt de mort du fonctionnement optimal de son application, puisqu'il part avec les règles de gestion dans son esprit.
- Pour toi, l'analyste implémente dans ses bases, chaque nouvelle règle de gestion, sans rechigner.
- Pour toi, l'analyste se plie, sans calendrier, aux évolutions permanentes des règles de gestion, exprimées par les gestionnaires.
- Pour toi, l'analyste contourne éventuellement l'usage approprié de ses tables, afin de ne pas trop refondre son MCD (inexistant, raison pour laquelle il ne s'y réfère jamais).
- Pour toi, une fois détournées, les tables, probablement patchées, ou assistées de traitements par code, peuvent "faire encore le boulot" (grosso merdo ?).
- Pour toi, un modèle conceptuel de données est une surcharge mentale.
- Pour toi, schématiser durablement et collectivement, des données stockées par l'entreprise, n'est pas un objectif.
- Pour toi, l'utilisateur ou le développeur, s’il souhaite s'informer sur l'objectif et le fonctionnement de son application, doit préalablement l'ouvrir, en comptant sur son intuition et sur la chance, pour trouver le chemin vers l'aide qu'il recherche.
- Le développement d'une application de gestion, de cette manière, est-il dès le départ, pensé, pour être terminé ?
- Les utilisateurs sont-ils (uniques) référents fiables pour garantir que tout se passe bien avec leurs outils ?
- Compte-t-on sur eux pour que, d'initiative, ils se forment les uns les autres ?
- Une application de gestion, développée de cette manière, est-elle dès le départ, pérenne ?
Est-elle transmissible à une filiale de l'entreprise, sans son développeur attitré, individu original singulièrement créatif, parmi les individus originaux singulièrement créatifs ?
- Pour mieux appréhender les problématiques métier, Merise 1/2 est-il sorti du formatage singulièrement créatif d'un seul informaticien, ou est-il le compromis écrit, d'un retour d'expérience collégial de plusieurs générations d'informaticiens ?
- Pragmatiquement, quel gâchis, d'alunir sur le projet de quelqu'un d'autre, qui s'est adonné à 'échapper des normes, s'échapper des cadres techniques, et s'échapper de la responsabilité de transmettre des spécifications !
- Quel dommage de se résoudre à réinventer, presque entièrement le travail de son prédécesseur !
- Les instructions données dans le cours MERISE, proposent de prendre conscience de formes régulières de conception : clef primaire, clef alternative, clef candidate, clef secondaire, clef étrangère, dépendance fonctionnelle, couverture, disjonction, héritage (exclusion, inclusion, totalité, partition), égalité, unicité, identification relative, CIM, CIF + association, double CIF, association réflexive, historisation...
Ces jargons sont-ils intentionnellement doctrinaux et insidieux ?
- Bravo à tous nos pionniers, qui ont payé le prix fort, en temps passé, à ouvrir la voie !
Je préfère prendre paresseusement les sentiers battus de conception et d'organisation, quand ils se présentent, formes régulières MERISE, collectivement identifiées, plutôt que de cheminer seul, sur ma route, content de moi, juge et arbitre.
J’avais anticipé ces réactions en prévenant que ma démarche risquait de heurter les esprits cartésiens éduqués à bien faire tout comme il faut.
Pourquoi juger sans savoir plutôt que chercher à comprendre et s’instruire de la diversité, d’un autre point de vue ? En restant dans sa bulle confort, cela ne fait que révéler une incapacité à concevoir autre chose que ce que l’on connait, de ce pour quoi on été formaté.
J’ai recensé vos supputations négatives, ridicules et stériles, basées uniquement sur le fait que je me passe d’un MCD et qu’il me suffit de visualiser mentalement les tables concernant la fonctionnalité que je développe.
Impressionnant ! Vos réactions virulentes font peur. Ce refus d’imaginer autre chose que ce que vous connaissez frise l’embrigadement. Le moindre de mes propos est déformé et amalgamé à votre vécu et vous vous permettez de supposer des absurdités sur ce qu’est une démarche bottom-up.
À méditer et à mettre en pratique : Le serment de non-allégeance de M. Cockburn :
« Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée. »
Quand des informaticiens ne savent pas écouter sans préjugés un autre informaticien, comment croire que ces mêmes informaticiens soient capables d’écouter une problématique métier à informatiser autrement qu’à travers le prisme de leur formatage. « Comprendre le métier de l'utilisateur pour lui créer les outils appropriés, ça n'est pas la même chose que le lui réinventer. », disait Guilip.
Quand on ne comprend pas un point de vue et que l’on ne cherche pas à le comprendre, il est plus facile de le rejeter en lui inventant mille défauts et en votant contre. Cela ne change en rien la réalité qui dérange. C’est juste nul, parce que ce manque d’ouverture d’esprit, ni n’honore, ni ne valorise.
Ma méthode de travail s’alimente d’autonomie, de pragmatisme, de liberté, de créativité, d’audace, d’initiatives, d’aventure, d’expérimentation, de défi, de prise de risques, d’adrénaline, de responsabilités, de professionnalisme, de nouveauté, d’incertitude, de surprise, de passion, de plaisir, d’empathie... Ça vous parle ? Ou votre acrophobie ne se soigne-t-elle que par des modèles, des formes normales et de la procrastination ?
Quelque soient les modèles et formes normales, la réalité, c’est qu’une BDD est constituée de tables et chaque table de colonnes. À partir de là, si le développement d’une fonctionnalité nécessite la création d’une table, et bien on la crée. Selon la table à créer, ça peut prendre moins d’une minute à quelques minutes.
Quand on démarre en développement bottom-up, il n’y a rien, juste un serveur, un développeur, des gestionnaires dans les starting-blocks qui attendent de pouvoir utiliser leur application et des milliers de personnes qui s’attendent à être convoquées incessamment. Cela demande d’être capable d’appréhender clairement la problématique métier, de savoir se projeter dans le futur proche, lointain, très lointain et de connaitre son métier, tout simplement. Ha, si !... Cela exige également de s’investir, d’avoir confiance en soi, de savoir prendre des risques.
Décidément, vous ne méritez pas que je vous consacre du temps. Aucun échange constructif, continuez donc à tourner en rond dans votre bulle confort.
Salut !
Rappel : La discussion est consultable ICI.
■ Des gestionnaires chefs de projet et un développeur traducteur
En immersion dans le service de gestion, la majorité des informations et des documents est directement accessible et compréhensible sans qu'il soit nécessaire de mener des interviews. Le chef de service peut s'étonner voire même s'inquiéter d'être si peu sollicité. La réalisation d'une fonctionnalité (une édition ou un écran) amène d'éventuelles questions qui trouveront leurs réponses directement auprès des interlocuteurs les plus pertinents : l'utilisateur final (le terminaliste), le chef de service.
« Comprendre le métier de l'utilisateur pour lui créer les outils appropriés, ça n'est pas la même chose que le lui réinventer. », disait Guilip.
Dans cette approche du développement, le dialogue développeur/chef de service se situe au même plan que le dialogue développeur-gestionnaires. Face à l'urgence des développements à réaliser, la hiérarchie n'est plus de mise. Le responsable de l’entité administrative n’apporte en fait pas grand-chose car il vit une autre réalité. Il connait la mission et les règles de gestion de son entité mais il ne s'intéresse pas forcément à la façon dont son personnel réalise cette mission et il ignore la plupart du temps comment ses gestionnaires mettent en œuvre les règles de gestion.
Ce n’est pas un reproche à son égard, ce n’est tout simplement pas son rôle, ses préoccupations se situent ailleurs. Et la meilleure preuve, c’est que naturellement rétif à l'informatique, il ne s’intéresse pas du tout au logiciel en cours d’élaboration et qu’il serait donc bien incapable de remplacer un(e) de ses gestionnaires si cela s’avérait nécessaire.
Concevoir un applicatif avec les seuls chefs de service pour interlocuteurs, c'est se priver d'une masse d'informations très riche susceptible d'orienter de façon pertinente les développements ; c'est créer un outil inadapté, intégrant sans doute les règles de gestion, mais occultant la réalité quotidienne.
Vivre le quotidien des gestionnaires permet de décoder ce qu’elles ne savent pas qu’elles savent. C’est en étant au plus près des gestionnaires que l’on décèle leur mode de fonctionnement. Il ne reste au développeur qu’à traduire, à structurer leur démarche avec ses outils, sa compétence, son vocabulaire.
Au quotidien, les gestionnaires travaillent sous la contrainte de leurs horaires à respecter, du rendement à produire et de la pression hiérarchique. C’est le soir, à la fin de leur journée que l’on apprend le plus, lorsqu’elles terminent leur service et s’apprêtent à rentrer chez elles. Libéré(e)s de leur entrave journalière, les gestionnaires se livrent facilement, émettent leurs idées, leurs souhaits. Ce moment privilégié dure très peu de temps, le temps de s’habiller, 5-10 minutes, un quart d’heure, car il faut aller chercher les enfants, faire quelques courses, acheter le pain. C’est pendant ce court laps de temps, hors ascendant hiérarchique, qu’elles se lâchent et osent rêver leurs vrais besoins. Et quelle surprise quand elles découvrent le lendemain matin sur leur bureau ce qu’elles avaient évoqué la veille au soir !
C’est là qu’il ne faut pas les décevoir. Quitte à y passer la nuit, réaliser un état qu’ils ou elles trouveront le lendemain matin sur le coin de leur bureau permet de gagner leur confiance.
Par ailleurs, l’utilisateur (le responsable de l’entité hiérarchique) s’attarde souvent après le départ de ses gestionnaires pour régler sereinement ce qu’il n’a pas eu le temps de faire dans la journée. C’est là aussi un moment privilégié pour communiquer.
Si le développeur reste dans son entité informatique et quitte lui-même son poste à l’heure officielle c’est sûr qu’il passe à côté d’informations essentielles.
Anecdote :
Développement classique :
- Le chef de projet interview la hiérarchie qui connait certes la mission de son service et sa réglementation mais qui ne s'intéresse pas forcément à la façon dont son personnel réalise cette mission.
- Le chef de projet informatise la problématique métier d’après ce qu’il a compris de la réglementation et impose sa vision aux gestionnaires qui doivent s’adapter. L’insertion d’un gestionnaire dans l’équipe de développement, quand elle a lieu, n’a qu’un seul objectif : faire accepter l’application développée par les autres gestionnaires.
Un des problèmes récurrents, c’est que le chef de projet ne s’adresse qu’au responsable de l’entité administrative (hiérarchie oblige), lequel très souvent ne voit ses gestionnaires qu’en termes d’horaires à respecter et de gestion de leurs congés.
Anecdote :
À l’inverse d’un développement classique (top-down) où c’est le développeur qui interview et sollicite l’utilisateur, ce sont les gestionnaires qui informent et sollicitent le développeur. Finalement, le développeur n’est pas un « développeur » mais un « traducteur » qui traduit leur langage métier en langage informatique. Il ne s’agit pas de penser à une solution mais de vivre et ressentir une solution. Le psychiatre américain Bruno Bettelheim appelait ceci : « Arriver à se mettre dans les chaussures de l’autre. »
L’activité la plus satisfaisante n’est pas coder mais comprendre le métier de l’utilisateur et savoir traduire ses fonctionnalités en fonctionnalités informatisées respectant son métier et non le lui réinventant. La créativité et le génie résident dans la conception des écrans, des états, des menus, des procédures. Le codage n’est qu’un des outils du développeur comme le rabot n’est qu’un des outils de l’ébéniste. La créativité et le génie de l’ébéniste s’expriment dans la conception et la réalisation de son meuble, pas dans la manipulation de son rabot. Cela n’empêche pas le développeur d’aimer programmer, ni l’ébéniste d’aimer manipuler son rabot.
■ Informatiser les processus annexes
Chaque nouveau cycle de la problématique de gestion offre l’occasion d’informatiser les processus annexes mis en attente et d’implémenter l’existant.
Grandes étapes d’informatisation de la Division de la Formation Continue et des Concours (DIFCA) :
Un processus annexe peut être géré par une entité administrative spécifique.
Février 1992 :
Septembre 1992 :
Octobre 1992 :
Octobre 1993 :
Septembre 1994 :
Septembre 1995 :
Septembre 1999 :
Mars 2000 :
Janvier 2003 :
Octobre 2004 :
Janvier 2006 :Informatisation FCPE (Formation Continue de Personnels Enseignants)
Informatisation des Examens-Concours
Informatisation de la gestion des membres du jury (Examen- concours)
Informatisation PNF (Plan National de Formation)
Informatisation comptabilité formateurs
Informatisation CAFA (Centre Académique de la Formation de l’Administration)
Unification des deux BDD FCPE + CAFA (Enseignants + Administratifs)
Passage à l’an 2000
Exportation Ex&Co à Versailles
Convocation des stagiaires par courrier électronique
Ordre de Mission formateur par courrier électronique
Gestion du concours des instituteurs (application nationale + Ex&Co)
Le choix de développer un processus annexe plutôt qu’un autre peut dépendre de l’organisation et/ou de la disponibilité, de l’assentiment de l’utilisateur et de ses gestionnaires.
FCPE : Gestion des formateurs, Gestion du Plan National de Formation (PNF), Bilans.
À l’origine, l’entité administrative était structurée en trois services distincts. Deux de ces services dont le service comptabilité chargé de gérer l’indemnisation des formateurs, étaient « allergiques » à l’informatique. Ils ne seront informatisés qu’à l’occasion de conditions plus favorables, réunies grâce à de nouvelles affectations de personnels. Leur informatisation conduira à une réorganisation de l’entité en « gestion intégrée ».
La gestion des formateurs bénéficiera des développements de la gestion des membres du jury d’Ex&Co. En effet, les formateurs et leurs prestations correspondent ni plus, ni moins qu’aux membres du jury et leurs travaux. À l’inverse, les examens-concours, épreuves, dates et lieux avaient pu profiter des développements des actions de formation, stages, dates et lieux.
Ex&Co : Gestion des membres du jury. Cette fonctionnalité sera développée au cours de la deuxième série d’examens-concours plus calme entre septembre et décembre.
Selon la problématique, le nombre de cycles peut facilement dépasser la dizaine :
FCPE : 17 cycles annuels.
Ex&Co : 15 cycles annuels.
■ Implémenter l’existant
Une fonctionnalité en apparence terminée a toujours un fil qui dépasse et qui ne demande qu’à être tiré (syndrome du « jamais fini »).
Dans un contexte « just in time », la priorité est de satisfaire le besoin immédiat et donc de proposer la meilleure solution possible dans l’instant, sachant qu’inévitablement des améliorations devront être apportées. L’existence même de la solution fait réagir l’utilisateur et ses gestionnaires, leur ouvre des horizons ; elle fait réagir également l’éventuel public concerné. Au fil du temps, chacun apporte sa petite contribution.
Le courrier électronique est devenu un outil de communication intéressant entre l’utilisateur et le développeur. Il permet à l’utilisateur de formaliser sa demande à sa convenance, sans qu’il soit nécessaire d’envisager un rendez-vous ou d’attendre d’être mutuellement disponibles. Pour exprimer sa demande l’utilisateur se voit obligé d’être concis. De plus, les paroles s’envolent et les écrits restent.
Chaque aménagement est consigné dans le mémorandum de l’application, ce qui permettra à posteriori de comprendre les choix de la solution, ceci dans l’optique d’un éventuel et futur développement « top down ».
Certaines fonctionnalités, négligées, appréhendées, voire redoutées dans un premier temps, peuvent se révéler très intéressantes et devenir indispensables.
Certains aménagements s’imposent souvent de façon inattendue. La réflexion ne peut pas tout prévoir et c’est le temps et la pratique qui permettent d’affiner une solution. Il est difficile d’expliquer la différence entre deux solutions, l’une émanant d’une démarche classique « top-down » et l’autre d’une démarche « bottom-up ».
Exemple simple d’une convocation de stagiaires :
En « Top-down », l’état comprend certes les informations utiles pour convoquer le stagiaire mais se limite à ça. Son développement a un début et une fin. L’objectif du développeur est de réaliser le programme en respectant les spécifications édictées par l’analyste, qui lui-même les a conçues d’après le cahier des charges du chef de projet. Il s’agit pour le développeur de respecter des délais, de réaliser un produit fini pour pouvoir passer à autre chose. La convocation créée résulte d’une compilation de données, hors contexte. Manipuler des données est une chose, capter des situations en est une autre.
Certes, des modifications peuvent toujours être demandées. Cela fait l’objet d’un « signalement » pris en compte par un correspondant informatique qui le transmet à l’équipe de développement. La réalité montre que lorsqu’une demande d’aménagement a une chance d’aboutir, les gestionnaires ne peuvent l’espérer avant deux ans.
En « Bottom-up », le développement n’a pas vraiment de fin. (syndrome du « jamais fini » selon James Martin). L’attention est sans cesse en éveil, ainsi la convocation est progressivement ciselée pour satisfaire diverses préoccupations :
- Son ergonomie est calquée sur celle des écrans de saisie des gestionnaires dans un souci « WYSIWIG » et conçue pour faciliter la lecture, la compréhension des destinataires, sachant qu’ils ne « lisent » pas, qu’ils « zappent ».
Objet et références sont mis en évidence pour faciliter la communication stagiaire-gestionnaire et un titre bien lisible « CONVOCATION » dans une police particulière identifie clairement le document pour ne pas le confondre avec le document équivalent destiné aux formateurs.
- Le timbre (en haut à gauche de la convocation) comprend les références de deux suivis, l’un administratif, l’autre pédagogique. Avec les références du seul suivi administratif, les gestionnaires servent de secrétaires aux responsables de formation et leur travail est inutilement interrompu pour uniquement transférer des appels téléphoniques aux formateurs.
Pour comprendre et trouver la parade à ces dérangements téléphoniques, il faut être proche des gestionnaires, vivre leur quotidien. Ce n’est pas un modèle conceptuel qui va inspirer ce genre d’attention.
- L’espace entre les dates et lieux de stages et la signature est délimité par un encadré précédé de cette phrase : « En cas d'empêchement majeur de participer au stage, veuillez retourner votre convocation avec le motif de votre désistement ». Ce cadre vide interpelle le stagiaire, le rend attentif à cette phrase et comprend ce qu’il doit faire s’il doit se désister. Les gestionnaires ne sont plus dérangé(e)s.
Cette disposition résulte de deux observations espacées de quelques minutes. La première a été formulée par une formatrice qui reprochait aux convocations d’être trop « tassées » vers le haut lorsqu’il y a peu de sessions dates et lieux. Évidemment, la convocation est issue d’un traitement informatique et non d’un traitement bureautique. Il n’est pas envisageable d’imprimer des convocations en fonction de leur nombre de sessions dates et lieux. La deuxième observation est venue des gestionnaires qui ne supportaient plus d’être interrompu(e)s par les appels téléphoniques des stagiaires leur demandant quelle était la procédure en cas de désistement.
Curieusement, plus l’espace disponible dans l’encadrement est important, plus le stagiaire qui se désiste argumente le motif de son désistement.
Ce n’est pas non plus un modèle conceptuel qui va inspirer cette autre attention.
D’autres logiciels de gestion de la formation existent. Un bref regard sur leurs convocations suffit pour percevoir les limites de la réflexion de leurs développeurs.
L’un d’entre eux a fait le choix, par exemple, de présenter les sessions date et lieux, non pas par ordre chronologique mais par ordre de lieux. Cela lui permet de n’imprimer qu’une seule fois un même lieu pour des dates différentes mais lorsqu’au milieu de ces dates figure une session dans un lieu différent, le stagiaire ne fait pas attention et ne se présente pas à cette session. Le développeur a résolu son problème d’impression mais a généré un problème d’organisation. Un formateur peut ainsi se retrouver sans stagiaires.
■ Assurer la veille technologique
Ce qui n’était pas envisageable à un instant T, peut le devenir grâce à une évolution technologique.
De nouvelles fonctionnalités peuvent devoir accompagner une évolution technologique comme par exemple l’utilisation du courrier électronique pour l’envoi de convocations :
Certaines évolutions, simplificatrices pour les uns, peuvent générer un phénomène de rejet pour d’autres en impactant leurs tâches ou en redistribuant les rôles.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17┌──────────┬────┬─────────────────────────────────────────────────────────────┐ │CF_LIST_0 │.lst│Création de la mailing-list des destinataires (N°) │ ├──────────┼────┼─────────────────────────────────────────────────────────────┤ │CF_ITEM_0 │.out│Création du destinataire en cours de traitement N°/nom/prénom│ │CONVOC_0 │.prt│Création du fichier d'impression de la convocation │ │iso2pcl │.pcl│Transformation des caractères semi-graphiques non reconnus │ │pcl2pdf │.pdf│Conversion de la convocation "PCL" en fichier "PDF" │ │CF_MAIL_0 │.mel│Création de l'adresse E-mail du destinataire du courrier │ │CF_MSG_0 │.msg│Création du message personnalisé │ ├──────────┼────┼─────────────────────────────────────────────────────────────┤ │mutt │ │Envoi de la convocation "PDF" en pièce jointe au message │ │ │ │"From" est paramétré dans : ~home/.muttrc │ │ │ │"ReturnPath" est paramétré dans : /etc/postfix/canonical.dbm │ ├──────────┼────┼─────────────────────────────────────────────────────────────┤ │CF_sh_0 │.prt│Impression de l'écran "sh" pour confirmer l'E-mailing REEL │ │ │ │("sh" = suivi historique) │ └──────────┴────┴─────────────────────────────────────────────────────────────┘
Exemple concernant la convocation des stagiaires
L’utilisation du courrier électronique a permis :
- de supprimer la signature par la chef de division (matinée du samedi),
- de supprimer la mise sous enveloppe des convocations par les gestionnaires (matinée du lundi),
- de supprimer la distribution par le service en charge du courrier.
Mais bien sûr, cela a eu pour conséquences
- d’imprimer les convocations par le secrétariat des établissements
- de déléguer leur signature aux chefs d’établissement
(remboursement des frais de déplacement, oblige),- d'inventer en amont, une nouvelle procédure de contrôle du chef de division,
- d'adapter la tâche des gestionnaires à la dématérialisation du processus de convocation.
Attention ! Automatiser au maximum, ce n’est pas laisser plus de temps aux gestionnaires pour réfléchir, mais au contraire, les conditionner à ne plus réfléchir.
I-1. Les règles de conception
▲ I-1.1. Développer au pied levé
► I-1.2. Développer à main levée
▼ I-1.3. Démarrer
Consulter le profil
Marquer ce blog comme lu
