Voir le flux RSS

Au Pied Levé - À Main Levée

I-0.1. SYNOPSIS

Noter ce billet
par , 01/04/2020 à 05h00 (132 Affichages)
APL-AML est une monographie qui axiomatise une approche du développement 100% ascendante (bottom-up).

Le développement n’est pas qu’une affaire exclusivement technique, c’est une alchimie mêlant savoir-faire (l’art) et savoir-être (la manière). L’Art se définit par des modalités pratiques d’exécution, des procédures opérationnelles, organisationnelles (règles métier) ; la Manière est gouvernée par une attitude, des obligations morales, (valeurs et principes). Règles et Principes modélisent l’Art et la Manière de développer.

Ce billet SYNOPSIS et un billet SOMMAIRE agrègent tous les billets du blog via des liens hypertextes.

APL-AML
(Au Pied Levé - À Main Levée)

Nom : Logo Art et Manière (140x140).png
Affichages : 21
Taille : 7,5 Ko

SYNOPSIS

AVANT-PROPOS

APL-AML résulte d’une aventure informatique autodidaxique dans un contexte administratif toujours compliqué, voire désespéré. Recherche des mécanismes du développement et parcours professionnel atypique, en dehors du système, se sont mutuellement impactés pendant 37 ans, de 1971 à 2007.

Le hasard, la coïncidence, la chance, l’initiative, ont profilé mon parcours d’homme providentiel : tour à tour programmeur « dernier recours » sans jamais faire partie d’une équipe de développement, chef de projet-développeur en moins d’une minute… dans un service de maintenance, et pour finir chef de projet-développeur d’applications locales concurrençant des applications nationales.

Les motivations de ce parcours : décloisonner le système, supprimer les intermédiaires qui déforment la réalité, comprendre les problématiques dans leur authenticité, se rapprocher de l’utilisateur jusqu’à développer dans son entité métier.

Au final, APL-AML est une monographie qui axiomatise une approche du développement 100 % ascendante (bottom-up).

Se référant à des développements internes (intra-administration), APL-AML ne subit pas l’asservissement aux « coûts-délais-cahier des charges » d’une prestation de services SSII.

L’informatisation d’une problématique résulte d’un contrat moral entre une entité métier (l’utilisateur et ses gestionnaires) et l’entité informatique (le développeur). Aux contraintes de délais se substituent l’immédiat et la permanence (Caractère de ce qui demeure ou de ce qui fonctionne sans interruption pendant une période de temps longue et indéterminée).

Un développement APL-AML s’initie immanquablement à partir d’un fait banal, une petite phrase anodine, une rencontre, une opportunité associée à une problématique en désespérance. Seule une situation désespérée peut inhiber le réflexe naturel d’une recherche d’informatisation contractualisée, sécurisante. L’informatisation nait alors d’un contrat moral entre le développeur et l’entité métier (l’utilisateur et ses gestionnaires).

« Si tu peux, fais quelque chose pour eux, ils valent le coup, moi je n’ai pas eu le temps. »
C’est ce que m’avait confié un collègue, juste avant son départ en province. Deux mois plus tard, la problématique était informatisée et l’aventure a duré deux ans. C’est à cette occasion que j’ai réalisé qu’il était possible d'informatiser une problématique de gestion, comme ça, à partir de rien, juste un nom, une adresse et un numéro de téléphone griffonnés sur un bout de papier.

« Tu peux aller voir ce qui se passe à l’Annexe, il se dit chaque lundi matin en réunion des chefs de division que la Formation Continue va dans le mur ; mais informatiquement, je ne les connais pas. »
C’est par cette simple sollicitation qu’une nouvelle aventure, démarrée en trois jours, va durer 17 ans…

« On s’est serré la ceinture toute l’année, du coup, j’ai un budget conséquent à dépenser avant la fin de l’année budgétaire, faites-moi une proposition. »
Deux mois plus tard, je démarrais en une journée l’informatisation du service des examens-concours, une autre aventure qui va durer une quinzaine d’années.

Toute ma carrière a été émaillée de ces instants, de ces petites phrases anodines à l’origine de mes challenges, de ces aventures dans lesquelles j’entrainais des utilisateurs et leurs gestionnaires, d’abord incrédules et plutôt inquiets puis très vite complices et enthousiastes.

APL-AML s’est nourri de ces expériences mais par simplicité, je ne me réfère qu’aux deux derniers développements réalisés dans le contexte idéalisé que j’ai toujours recherché, à savoir le développement in situ, au pied levé, à main levé.

Les développements

La DIvision de la Formation et des Concours Administratifs (DIFCA) du Rectorat de l'académie de Créteil comprend trois services :

  • FCPE : Formation Continue des Personnels Enseignants du second degré,
  • CAFA : Centre Académique de Formation de l'Administration,
  • SECA : Service des Examens et Concours Administratifs.

Deux applications seront développées entre mi-mai 1991 et fin septembre 2007.

Le calendrier des démarrages s'est présenté comme suit :

  • 1991 : FCPE - Gestion des stagiaires
  • 1992 : SECA - Gestion des candidats puis des jurys
  • 1993 : FCPE - Gestion des formateurs
  • 1995 : CAFA - Gestion des stagiaires et des formateurs
  • 1996 : FCPE et CAFA - Fusion des deux BDD Formation Continue
  • 2000 : Exportation de l'application Ex&Co à Versailles

Les deux Bases de données en quelques chiffres au 31 juillet 2007 :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌─────────────────────────┬─────────────────────────────┬─────────────────────────────┐
│                         │ OSMOSE (Formation continue) │ Ex&Co (Examens et Concours) │
├─────────────────────────┼────────────┬────────────────┼────────────┬────────────────┤
│            Gestionnaires│   35       │                │    10      │                │
│       Procédures (shell)│   982      │  105.567 lignes│   251      │   41.218 lignes│
│           Éditions (ace)│   916      │  581.732 lignes│   205      │  147.478 lignes│
│Requêtes applicatif (sql)│   330      │   30.110 lignes│    77      │    5.060 lignes│
│  Requêtes diverses (sql)│   928      │  184.049 lignes│   445      │   61.536 lignes│
│             Écrans (per)│   136      │  434.778 lignes│   900      │  969.648 lignes│
│                   Divers│   415      │   59.077 lignes│   321      │   56.196 lignes│
│                     Menu│ 7.343 items│    7.343 lignes│35.567 items│   35.567 lignes│
│               Tables BDD│   205      │                │    66      │                │
│                Synonymes│    59      │                │     9      │                │
│                     Vues│   128      │                │   194      │                │
│                Attributs│ 5.271      │                │ 2.515      │                │
├─────────────────────────┼────────────┼────────────────┼────────────┼────────────────┤
│                         │            │1.402.656 lignes│            │1.316.703 lignes│
└─────────────────────────┴────────────┴────────────────┴────────────┴────────────────┘
Environnement de développement

  • Système : UNIX SCO puis AIX
  • SGBD/R : Informix ESQL


▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬


APL-AML

(Au Pied Levé - À Main Levée)


« Dans un groupe, la communication doit devenir un partage d’expérience, à ne pas confondre avec l’information qui est un partage d’idées. Pour y arriver, il faut valoriser les divergences, chercher la solution dans ce que chacun peut apprendre à l’autre, plutôt que dans ce que chacun veut prouver à l’autre. Le collègue de travail qui pense autrement, loin d’une menace, est notre seule façon d’apprendre quelque chose de nouveau. Nous avons donc tous besoin d’utiliser l’inconnu plutôt que les certitudes pour progresser dans la vie. »
Bertrand Piccard

« 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. »
Le serment de non-allégeance de M. Alistair Cockburn

« Une photo tout de suite ! » C'est ce à quoi aspirait Edwin LAN en inventant le Polaroïd, appareil photo à développement instantané.

« Une application tout de suite ! », c'est le développement instantané… d’application que propose APL-AML avec son concept « ask and use », concept qui peut être perçu comme étant au soft ce que la technologie « Plug and Play » est au hard.

On ne sait pas ce qui va se passer demain, dans un mois, dans six mois, dans un an… C’est un sentiment de liberté totale, de pulsion créative, c’est ce qui fait vibrer, c’est ce qui fait entreprendre. Ce ne sont pas les règles classiques du développement top-down qui structurent et standardisent la réflexion mais les besoins immédiats de la problématique qui en sont le moteur et l’inspire. Cela ne signifie pas ignorer pour autant les règles classiques du développement, il ne s’agit pas de les appliquer mais de les utiliser. Le développement n’est pas un travail d’ouvrier spécialisé mais véritablement une œuvre de l’esprit.

Rien de ces pages n'est définitif, encore moins une vérité absolue. Tout y est provisoire, à améliorer et à remettre à jour - indéfiniment. C’est juste un discours avec moi-même pour comprendre ce qu’il y a de commun à toutes mes aventures, pour structurer ma pensée, pour découvrir, révéler, apprendre ce que j’ignore savoir. C’est juste une thérapie pour apaiser ma conscience, une histoire personnelle pour livrer à ceux qui me font l'honneur de s'y intéresser mon expérience et mes convictions intimes. On dit qu'écrire, c’est organiser le « bordel » que l’on a dans la tête.

L’art a ses règles, la manière ses valeurs et ses principes.

Le développement n’est pas qu’une affaire exclusivement technique, c’est une alchimie mêlant savoir-faire (l’art) et savoir-être (la manière). L’Art se définit par des modalités pratiques d’exécution, des procédures opérationnelles, organisationnelles (règles métier) et la Manière est gouvernée par une attitude, des obligations morales, (valeurs et principes).

La dualité Art-Manière, c’est le Yin (l’art et ses règles) et le Yang (la Manière et ses principes).

Règles et principes modélisent l’art et la manière de développer.

  1. L’ART (L’art au sens des usages en vigueur dans un corps de métier)

    Les règles métier (ou règles de gestion, ou « business rules » en anglais) sont des prescriptions propres à une science, une technique, une activité déterminée, des spécifications, des déclarations structurées de haut niveau qui permettent de contraindre, contrôler et influencer un aspect du métier.

    Les règles métier, considérées comme seules exactes, autorisées, permettent de diminuer ou d’augmenter l'impact de risque et de prendre des décisions rationnelles. Il importe de les suivre dans leur étude, leur pratique.
    Travailler dans les règles de l’art, c’est observer de bonnes pratiques, exercer un savoir-faire, respecter les usages en vigueur. Pour un informaticien, c’est la maitrise des méthodes de conception et de réalisation.

    Lorsque ces méthodes défaillent, le réflexe est de surajouter de la maitrise, de la complexité au lieu d’envisager de transformer l’impossible en possible, de trouver des solutions, se remettre en question dans toutes nos stratégies en sortant des sentiers battus, des certitudes et des habitudes, en prenant tous les chemins de traverse, pour entrer dans les doutes et l’inconnu, en saisissant toutes les occasions de stimuler notre créativité, d’inventer de nouvelles solutions, de faire ce que les autres n’osent pas faire ou pensent être impossible.

    L’être humain a horreur du vide et veut à tout prix remplir tous ses doutes par des explications.

    1. Les règles de conception

      Processus de synthèse (bottom-up) et non d’analyse (top-down), il n’y a pas d’étude préalable, pas de cahier des charges, pas de modélisation… Rien ! Partir de quelque chose, ne serait-ce même que d’un existant informatisé obsolète, se révélerait une contrainte avec laquelle il faudrait composer et qui flouterait la réalité, la pureté de la problématique. Démarrer en terrain vierge n’est pas une situation subie mais choisie. On avance librement, sans fil à la patte, confiant dans son savoir-faire.

      Toutes les méthodes, quelles qu’elles soient ont pour objectifs d’organiser, de maitriser, d’identifier, de référencer, de baliser, de planifier, de prévoir, de corseter…

      APL-AML ne s’appuie sur aucune recette (Appliquer une recette, c’est se mettre dans des rails avec pour principal objectif de ne pas dérailler). L’investissement est intégralement consacré au développement proprement dit, sans procédures intermédiaires chronophage, réductrices de liberté, donc de vélocité.

      Professionnellement, le développeur est censé posséder les bases de son métier. Il ne s’agit pas pour lui d’utiliser des techniques sophistiquées coûteuses, difficiles à mettre en œuvre et à maintenir. L’important est de toujours maitriser ce qu’il crée, donc d’utiliser une technicité simple et économique. Le souci du développeur n’est pas de se préoccuper de maintenir sa compétence technique au plus haut niveau mais d’acquérir celle dont il a besoin le moment venu.

      À l’inverse d’une démarche « top-down » qui correspond à la décomposition progressive du complexe au simple de Descartes, la démarche ascendante « bottom-up » d’APL-AML (à partir des besoins) correspond à la maîtrise progressive d’éléments simples que l’on combine pour cheminer vers une complexité de plus en plus grande : on va du simple au complexe.

      Les règles conceptuelles se limitent à la liste chronologique des étapes assujetties à la démarche, chaque étape laissant libre cours à la créativité que la Manière stimule.

      1. Développer Au Pied Levé

        • Développer in situ
        • Un projet
        • Une aventure
        • Une task force (force opérationnelle)
        • Développer Au Pied Levé
        • Une démarche personnelle, individuelle ?

      2. Développer À Main Levée

        • Concept « ask and use »
        • Structurer l’inconnu
        • Écouter son intuition plutôt que sa logique analytique
        • 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 »
        • Idéation
        • Programmation mentale
        • Développer chaque fonctionnalité « juste-à-temps »
        • Des gestionnaires chefs de projet et un développeur traducteur
        • Informatiser les processus annexes
        • Implémenter l’existant
        • Assurer la veille technologique

      3. Démarrer

        • Prémices
        • Étude de l’existant
        • Étude préalable
        • Démarrage effectif
        • Création de la BDD
        • Création d’un menu « light »
        • Création du référentiel métier
        • Création de la nomenclature (catalogue)
        • Vues BDD

      4. Arrêter

        • Intégrer la solution adhocratique dans le système bureaucratique
        • Redévelopper classiquement
        • Abandonner la solution adhocratique

    2. Les règles de réalisation

      On n’est pas obligé de succomber au « toujours plus de technicité » qui crée des besoins inutiles, qui sophistique des développements compliqués à mettre en œuvre puis à maintenir.

      La sophistication à rechercher n’est pas dans la technicité informaticienne mais dans la procédure administrative, la convivialité des interfaces écrans et des é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. Les règles de réalisation se réduisent à quelques spécificités et pratiques classiques de la programmation. Ce sont des règles de bon sens et non des règles directives.

      L’essentiel de la démarche, c’est pour l’ensemble de la réalisation, la préoccupation permanente - à tous les stades du développement - de la perception des acteurs : utilisateur, gestionnaire, destinataire, informaticien, développeur. La plus grande attention porte sur la communication, la simplicité, l’uniformité, la cohérence, la pérennité, la qualité, la convivialité, la lisibilité, la traçabilité.

      1. Les bonnes pratiques de développement

        1. Brainwriting
        2. Mémorandum
        3. Liste chronologique des fonctionnalités
        4. Charte graphique
        5. L’espace de travail improvisé du développeur APL-AML

      2. Les bonnes pratiques de programmation

        1. Règles de nommage
          • Noms des tables
            • Initiales de l’application
            • Nommage des tables
          • Noms des données
            • Normalisation sémantique et syntaxique
            • Tables de références
            • Variables
            • Clés primaires et clés étrangères
            • Références croisées TABLES/ATTRIBUTS
            • Discussion « Modélisation des tables et des vues »
          • Noms des programmes
            • Écrans, états, shells, sql, sed, files

        2. Règles de développement
          • Les écrans
            • Structure d’accueil
            • Convivialité
            • Ergonomie
          • Les états
            • Structure d’accueil
            • Formulaires
            • Commandes HP PCL 5 et GPL/2
          • Les shells
            • Adoption d’un standard
            • Exemple de shell invoqué via un item du menu ou depuis le prompt
            • Exemple de shell avec une fonction récursive
          • Le système de menus
          • La beauté du logiciel

        3. Méthodologie de programmation LCP

        4. La programmation mentale
          • Le calcul mental
          • Programmer mentalement
          • Utiliser sa mémoire procédurale plutôt que sa mémoire immédiate
          • Sophrologie et apprentissage procédural
          • Programmation spontanée
          • Flash
          • Apprendre / Comprendre

      3. Documentation et outils développeur

        1. Environnement de Développement Intégré (EDI)
          • Les éditeurs de texte
            • L’éditeur de texte vi (unix)
            • vim et Emacs (unix, linux)
            • Sprint (ms/dos)
            • sed (unix)
          • L'EDI du SGBD Informix
            • Les outils permettant d’intervenir sur la BDD
            • L’accès à la BDD via un système de menus (ISQL)
            • Le langage SQL
            • Le compilateur d’états (saceprep)
            • Le compilateur d’écrans (sformbld)
            • Le système de menus
          • Les autres outils
            • pcl2pdf
            • Mailer Bull mutt (AIX)
            • Shell utilisant pcl2pdf et mutt

        2. AGL minimaliste
          • Les shells d'administration
            • Installation de l’applicatif
            • Sauvegarde de l’application pour exportation
            • Sauvegarde de l’application
            • Restauration de l’application
            • Sauvegarde du system
          • Les écrans d'administration
            • Administration du system catalog
            • Administration des développements
          • Les éditions d'administration
            • Arborescence
            • Dictionnaire des Données
            • Liste des tables
            • Liste des écrans
            • Liste des états
            • Liste chronologique des fonctionnalités
          • Les utilitaires
          • La documentation développeur
            • L’application est un tout
            • Chaque programme est un tout
          • Une documentation à postériori
            • Un outil de formation
            • Un cahier des charges atypique
            • Des diaporamas PowerPoint

      4. Documentation utilisateur

        1. Manuel utilisateur
          • Formation utilisateurs
          • Communication développeur-utilisateur
          • Newsletters
          • Documentation gestionnaires

    3. Annexes

      Ces annexes regroupent des extraits de développements réels réalisés entre 1991 et 2007. Plusieurs Billets du Blog s’y réfèrent plutôt que de les intégrer. L’objectif de les rassembler est pédagogique. Quelques Billets proposent parfois d’autres extraits pour illustrer leur thématique.

      Ces sources n’ont pas vocation à apporter des réponses techniques à certaines problématiques. Ils révèlent simplement la réalité d’un type de développement en informatique de gestion.

      Deux Billets Annexes concernent la création et la gestion de la BDD concours dans son intégralité (tables et index).

      Deux autres Billets Annexes concernent la création et la gestion de la BDD osmose (tables et index). Pour des raisons de volume, les fichiers sql ont été limités aux tables essentielles de la BDD.

      Il n’existe pas de MCD. Ce sont les besoins dans l’instant qui ont suscité la création de chaque table et de ses index.


  2. LA MANIÈRE (Principes méthodologiques, psychologiques et philosophiques)

    La Manière c’est l’état d'esprit adopté par le développeur lors de ses développements. Cette Manière est gouvernée par une attitude, des obligations morales, des valeurs, des principes méthodologiques, psychologiques et philosophiques.

    Valeurs

    Les valeurs sont subjectives et ne dépendent que de l’importance qu’on leur accorde, mais elles n’ont pas de prix car c’est en fonction d’elles, conscientes ou non, que chacun détermine ses choix d’action. Elles sont loin d’être un choix théorique car c’est notre « boussole interne » qui guide nos actions, permet de nous réaliser, nous fait avancer dans la vie en étant en accord avec nous-même.

    Les identifier revient à connaître ce qui sous-tend toutes nos pensées, tous nos projets, toutes nos actions. L'important est de trouver ses principales sources de motivation.

    Valeurs sociologiques : elles peuvent construire une éthique personnelle, orienter les actions des individus dans une société en fixant des buts et des idéaux.

    Valeurs humaines : ce sont des vertus qui nous guident pour prendre en compte l’humain lorsqu’on interagit avec un autre être humain.

    Valeurs du Manifeste : sociologiques et humaines, elles impactent l’équipe de développement et la collaboration utilisateur/développeur. Outre leurs vertus, leur respect par tous les acteurs joue un rôle de rassemblement.

    Principe

    C’est à la fois ce qui précède et ce qui régit les choses qu'on lui rapporte.

    C’est une source, un fondement, une vérité première d'idées, les premiers préceptes, les premières règles d’un art, quant au fonctionnement d’une chose. C’est une notion importante de laquelle dépend tout développement ultérieur en toute connaissance.

    C’est une maxime morale que l'on se donne, définissant une règle de conduite, une manière type d'agir sans préjuger des modalités pratiques d'exécution.

    C’est une norme constituant une référence fondée sur des considérations théoriques, des valeurs sur lesquelles il convient de régler une action ou sa conduite.

    C’est une cause active de quelque chose, un élément qui a la propriété de produire certains effets.

    C’est une loi de portée générale relative à une science, non démontrée mais vérifiée par ses conséquences que certaines observations ont d’abord rendue vraisemblable.

    Principes méthodologiques

    Un principe « management » se distingue d’un principe « développement » en ce qu’il concerne des personnes et non une procédure. Manifeste Agile, RAD, APL-AML… chaque méthode prescrit ses propres principes liés au management et/ou au développement :

    • Principes du Manifeste Agile (Management)

      Le Manifeste concerne le management des équipes de développement et non le développement proprement dit. En distinguant Valeurs et Principes, il traduit bien la perception des 17 leaders-managers qui l’ont rédigé.

      Reproduire le texte original du Manifeste n’ayant aucun intérêt, ses valeurs et principes sont ici regroupés par niveaux conceptuels, tels qu’ils peuvent être perçus par des développeurs et non des managers.

    • Principes du RAD (Management/Développement)

      Le « RAD » de Jean-Pierre Vickoff évoque des principes sans en dresser une liste à l’instar du Manifeste. Il s’agit donc de déductions extraites de son ouvrage.

    • Principes de l’Adhocratie (Management)

      Aucune ambiguïté sur la typologie de ses principes puisque l’ouvrage dont ils sont extraits « La stratégie des équipes ad hoc » ne se réfère pas du tout à l’informatique.

      Schématiquement, l’adhocratie qualifie toute forme d’organisation qui va à l’encontre de la bureaucratie pour aborder le changement.

      Concrètement, ce sont des collaborateurs compétents de départements différents de l’entreprise qui entreprennent de solutionner des problèmes communs à l’ensemble de cette entreprise, en transgressant si nécessaire les règles bureaucratiques telles que les organigrammes, les départements, les fonctions, les profils de poste, la hiérarchie et la tradition.

    • Principes APL-AML (Management/Développement)

      Et si je relisais mon texte en sélectionnant les concepts les plus significatifs de ma démarche pour les ériger en principes…

      APL-AML est en accord avec la plupart des principes du Manifeste mais n’est pas pour autant une méthode agile dans la mesure où le Manifeste s’adresse à des équipes de développement en SSII alors qu’APL-AML est une démarche individuelle, personnelle, en intra-entreprise.

    • Principes communs Adhocratie/RAD/Agile

      Exprimés différemment, certains principes abordent les mêmes sujets. Il est intéressant de les corréler.

    Principes psychologiques

    La Manière, c’est aussi l’attitude qu’enseigne la vie et qui a également ses principes. C’est l’engagement, c’est la liberté qui ne range pas tout dans des cases, une liberté qui s’alimente d’inhabituel, d’opportunisme, de coïncidences, d’intuitions, d’initiatives prémonitoires, d’irrationnel, d’irrespect des règles et du modèle pour devenir pleinement réactif.

    Lorsque le développement fait appel à plusieurs spécialistes installés confortablement dans leur bulle confort, aucune place n’est laissée à l’imprévu.

    L’exercice quotidien d’un métier génère des habitudes, des raccourcis qui font oublier le processus de certaines pratiques. C’est vrai pour les gestionnaires qui ne savent pas qu’ils savent mais également pour le développeur que je suis et qui doit s’observer lui-même avec suffisamment de recul pour décrypter son mode de fonctionnement. C’est en cherchant à comprendre et à expliquer le démarrage, l’évolution, la progression de mes informatisations, que j’ai mis en évidence l’influence d’événements imprévus, d’opportunités et de coïncidences. Cette irrationalité qui s’oppose au cartésianisme atavique de l’informaticien est néanmoins une constante d’APL-AML. Ce n’est pas une règle mais un simple constat. L’attitude vis-à-vis des personnes et des événements favorise sans doute le phénomène.

    Curieusement, certains événements ouvrent des perspectives, des opportunités débloquent une situation en impasse, des coïncidences simplifient une complexité…

    Cette Manière, APL-AML la nomme véloce attitude, un terme générique qui associe :


    1. Poulpe attitude : Utiliser son intuition pour prendre les bonnes décisions

      La poulpe attitude consiste à :

      - susciter les évènements
      - saisir les opportunités
      - exploiter les coïncidences

      Adopter la poulpe attitude, c’est savoir sans savoir, autrement dit c’est l’écoute de soi-même, se fier à son intuition pour agir et réagir plus efficacement au quotidien sans réflexions interminables, raisonnements logiques conscients ou schémas compliqués.

      Une personne qui ne sait pas s’écouter est condamnée à obéir aux autres, que ce soit ses parents, ses professeurs ou ses employeurs. C’est pourquoi une personne qui n’écoute pas son intuition est une personne qui n’utilise pas sa liberté. Le problème, c’est qu’on n’apprend pas à l’école à s’écouter soi-même.

      L’intuition, c’est se rebrancher sur son moi authentique et sa petite lumière interne. Ce n’est pas une science exacte, c’est une sensibilité artistique qu’on développe, comme le fait d’être mélomane ou cinéphile.

      Ne pas réfléchir intellectuellement mais instinctivement : 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.

    2. Positive attitude : Vivre en mode chance, savoir lire la vie

      Notre spécialité, pour la plupart d’entre nous serait plutôt la concentration, c’est-à-dire la capacité à nous focaliser sur une idée, un travail ou une action, en faisant justement abstraction de tout ce qui nous entoure et pourrait nous distraire de la tâche entreprise. C’est en tout cas comme cela que nous avons été éduqués pendant nos années de formation, que ce soit à l’école ou à l’université. Et c’est encore souvent ce qui est attendu de nous dans notre vie professionnelle.

      Vivre en mode chance, c’est regarder différemment sa propre façon d’être dans le monde, prendre les décisions adéquates, décider de faire ou ne pas faire les choses, anticiper la situation à venir, entrer ou non en relation avec les autres, être plus attentif que d’autres face à l’apparition des occasions favorables, fussent-elles issues du seul hasard ; saisir les occasions et rebondir sur les incidents de parcours…

      La chance est bien évidemment totalement irrationnelle et choque à bon droit notre sens commun d’héritiers de la modernité et de l’esprit scientifique. Hasards et coïncidences sont en fait des rencontres accidentelles entre des évènements qui ressemblent furieusement à des rencontres intentionnelles, à du « hasard apprivoisé » dirait Adrien Vescovi.

      Cette chance, comprise comme la capacité à tirer parti des circonstances, est aussi et avant tout une ressource. Sans doute moins maitrisable que d’autres, souvent plus impalpable, mais une ressource quand même, bien réelle et dotée d’une puissance extraordinaire pour qui sait en décrypter les promesses, en respecter les principes et les règles.

    3. Impulse attitude : Apprivoiser l’inconnu, s’investir totalement et librement, se mettre en danger pour devenir performant

      L’Impulse attitude, c’est apprivoiser l’inconnu, accompagner pour les utiliser, les événements qu’on ne peut pas changer.

      L’Impulse attitude, c’est stimuler la conscience de soi dans l’instant présent, c’est sortir de sa bulle confort, se confronter au risque, se mettre en danger pour devenir performant, pour réaliser ce qui parait impossible, c’est avancer librement, en envisageant toutes les options, c’est devenir un être responsable qui a le droit de se fonder sa propre vision du monde.

      L’Impulse attitude, c’est s’insurger contre la quête de la maitrise et du contrôle, de la réponse à toutes les questions, de la construction de certitudes rassurantes ou d’explications toutes faites, c’est penser dans toutes les directions et à tous les niveaux à la fois, sans aucune restriction.

      L’Impulse attitude, c’est apprendre à ne rien faire sans comprendre pourquoi on doit le faire. Pour celui qui a toujours voulu comprendre avant de croire quoi que ce soit, il est impossible d’accepter un dogme ou une doctrine ; impossible de prendre comme une vérité immuable une affirmation officielle décrétée par une instance religieuse ou philosophique sous prétexte qu’elle est la garante de la juste façon de croire. Se référer à la certitude d’une doctrine nous fait perdre la qualité du message d’origine.

      L’Impulse attitude, c’est cet esprit d’aventure, cette saveur qu’on vit, qu’on ressent, qu’on éprouve, qui donne envie de chercher la suite du chemin.

    4. Running attitude : Défier, s’adapter, maîtriser, découvrir, être libre, autonome…

      L’athlétisme est un humanisme, la course à pied, une école de la vie. Ses valeurs construisent une personnalité propice entre-autre au développement.

      La Running attitude, c’est améliorer sa performance en utilisant la préparation mentale et les techniques de conscience réfléchies employées par les athlètes, comme la sophrologie et la technique de visualisation qui consiste à créer des images mentales de leur succès pour les aider à se préparer et à maintenir la confiance en leur performance. La course à pied et la sophrologie empruntent le même vocabulaire : visualisation, autonomie, sérénité, harmonie, relaxation, plaisir, confiance, équilibre, respiration, zénitude.

      Courir, est un moment intense, très fort, indicible, peu racontable, un rituel religieux où l’on se prépare à quitter le monde profane pour rejoindre le monde du running… c’est mystique !

      C’est un moment privilégié pendant lequel on est en accord avec soi, pendant lequel les sens s’aiguisent. Le corps fait quelque chose mais l’esprit est ailleurs et se trouve dans un état maximal de concentration, de plein engagement et de satisfaction dans son accomplissement.

      Le cerveau, libéré de tâches qui lui demandent de focaliser son attention, continue d’être actif sous une forme que les neuroscientifiques ont appelé « mode par défaut ». Ce mode par défaut rejoue, analyse et déduit des éléments à partir de nos expériences passées, notre cerveau peut enfin mettre de l’ordre et favoriser la venue d’idées lumineuses.

      Ce temps de repos – sans écrans – est très productif et aussi nécessaire que l’est le sommeil.

      C’est un accélérateur de réflexion, un moment particulier pendant lequel le cerveau se met à fonctionner, à être créatif, à résoudre des problèmes. Alternativement en suspension et en appui au sol, si une préoccupation professionnelle occupe nos pensées, l’esprit libre ose tout, imagine tout mais reste en même temps rationnel et trouve la solution.

      En se préparant mentalement à la tâche à venir, on devient capable de réaliser des tâches de façon plus effective et efficace, de gagner du temps dans la durée et de faire un meilleur travail.

      Soumis à toujours plus de stress cognitif, trouver de l’espace dans notre cerveau pour réaliser une tâche, accroitre son potentiel en termes d’attention et de concentration est un atout inestimable.

    Principes philosophiques

    La philosophie comme mode de vie et non pas uniquement comme une réflexion théorique, c’est vivre et agir d’une certaine façon et non pas seulement se confronter à des questions abstraites.

    C’est mettre en application dans sa propre vie des résultats de la réflexion philosophique.


  3. BIBLIOGRAPHIE


  4. WEBOGRAPHIE





Au Pied Levé - À Main Levée

► I-0.1. SYNOPSIS
▼ I-0.2. SOMMAIRE

Envoyer le billet « I-0.1. SYNOPSIS » dans le blog Viadeo Envoyer le billet « I-0.1. SYNOPSIS » dans le blog Twitter Envoyer le billet « I-0.1. SYNOPSIS » dans le blog Google Envoyer le billet « I-0.1. SYNOPSIS » dans le blog Facebook Envoyer le billet « I-0.1. SYNOPSIS » dans le blog Digg Envoyer le billet « I-0.1. SYNOPSIS » dans le blog Delicious Envoyer le billet « I-0.1. SYNOPSIS » dans le blog MySpace Envoyer le billet « I-0.1. SYNOPSIS » dans le blog Yahoo

Mis à jour 02/08/2020 à 18h25 par APL-AML

Catégories
Programmation , ■ APL-AML

Commentaires

  1. Avatar de APL-AML
    • |
    • permalink
    Citation Envoyé par Invité Voir le message
    … le Carrousel des Billets de Blog (ci-dessus, en bas de chaque Billet) fonctionne à l’inverse :

    • Clic à gauche affiche le Billet suivant
    • Clic à droite affiche le Billet précédent
    L’incohérence vient de ce que le Carrousel défile les billets selon l’ordre chronologique croissant de leurs dates-heures de publication (donc de la plus ancienne à la plus récente) alors que la Liste des billets affiche ces mêmes billets (logiquement) par ordre décroissant de leurs dates de publication (donc de la plus récente à la plus ancienne).

    Il y a deux façons d’utiliser son blog :

    • Soit on y empile ses billets sans intention de les ordonner selon une logique particulière,
      et dans ce cas, la possibilité offerte de gérer l’ordre chronologique des billets n’a pas vraiment d’intérêt :
      Précédent ou Suivant, il s’agira tout simplement d’un autre billet ;

    • Soit on gère son blog en le structurant selon une logique par thèmes, par chapitres, etc.
      et dans ce cas, l’ordre chronologique des billets prend tout son sens… à condition que l’ordre logique (thèmes, chapitres, etc.) corresponde bien sûr à l’ordre chronologique croissant (dates-heures de publication)... Ce qui n'est pas le cas.

    Afficher la Liste des billets par ordre décroissant est un choix. Il faut juste en comprendre les inconvénients, à savoir qu’avec le carrousel du site, le billet suivant affiche bien le billet chronologiquement supérieur mais logiquement inférieur et que le billet précédent affiche bien le billet chronologiquement inférieur mais logiquement supérieur.

    Liste des billets (ordre décroissant des dates-heures de publication)

    Billets Dates de publication planifiées
    SOMMAIRE 06/01/2020
    Chapitre n° 1 05/01/2020
    Chapitre n° 2 04/01/2020
    Chapitre n° 3 03/01/2020
    Chapitre n° 4 02/01/2020
    Chapitre n° 5 01/01/2020

    Si l’on affiche le Billet « Chapitre n° 3 » :

    • Clic à gauche (billet précédent) sur le Carrousel affichera le billet « Chapitre n° 4 » (de date inférieure) mais correspondant logiquement au Chapitre suivant.

    • Clic à droite (billet suivant) sur le Carrousel affichera le billet « Chapitre n° 2 » (de date supérieure) mais correspondant logiquement au Chapitre précédent.

    Tout le monde a suivi ?

    Pour palier cette incohérence, chaque billet de ce blog propose en fin de billet son propre carrousel.

    Concernant ce billet précisément, son carrousel indique bien que le billet suivant est le billet ▼ I-0.2. SOMMAIRE alors que le carrousel du site, indique ce même billet comme billet précédent.
    Mis à jour 04/07/2020 à 15h06 par APL-AML