I-1.1. Développer Au Pied Levé

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 ■ ■ ■

  • Développer in situ
  • Un projet
  • Une aventure
  • Développer Au Pied Levé
  • Une démarche personnelle, individuelle ?

Développer in situ

Le concept s’est imposé immédiatement, en réaction à la méthode classique top-down « étude-préalable/cahier-des-charges/analyse/programmation » produisant trop d’applications de gestion en situation d’échec. Un haut responsable métier ira même jusqu’à considérer que son application n’existe pas et refusera par la suite de recevoir les informaticiens.

En cause : le cloisonnement, l’incompréhension de deux mondes, celui des entités métiers et celui des informaticiens. Les deux mondes ne savent échanger qu’entre responsables de même niveau hiérarchique à travers l’incontournable hygiaphone : la feuille d’interview hier, les users-stories aujourd’hui. Leur incompréhension n’est qu’un bête problème de communication que les informaticiens ne savent résoudre que par leur technique. L’utilisateur transmet certes l’information mais en la déformant de multiple façons, en l’exagérant, en l’occultant, en l’inventant.

« Communiquer, c’est davantage que transmettre des informations. »

CHANGER D’ALTITUDE – Bertrand PICCARD

Ce que nous croyons être un dialogue entre deux individus, n’est en réalité que deux monologues. Le premier a lieu entre nous-même et notre imaginaire et le second entre notre interlocuteur et son propre imaginaire.

Quand on parle à quelqu’un, les mots que l’on prononce correspondent, lorsqu’ils sortent de notre bouche, à une image, une émotion ou une représentation que l’on pense être très claires et univoques dans notre esprit. Du côté de notre interlocuteur, il n’en sera pas de même. Les mots arriveront soit sur un terrain vierge, où ils devront être décodés, puis interprétés, soit sur un terrain familier, où ils seront tout de suite associés à des images, émotions ou représentations personnelles, qui peuvent se révéler différentes des nôtres. À défaut d’expérience commune, notre interlocuteur essayera de construire la situation dans son imagination, mais nous devrons rester conscients du décalage inévitable que cela engendrera.

Une idée ou un ressenti qui passe dans notre conscience sera traduit en mots (première déformation) pour être communiqué à notre vis-à-vis (deuxième déformation). Ce dernier comprendra les mots comme il peut (troisième déformation) pour les retraduire en idées ou ressentis (quatrième déformation) qui seront intégrés en fonction de son propre vécu (cinquième déformation).

Il faut bien comprendre que quelqu’un qui entend nos paroles, il les passe au filtre de ce qu’il est prêt à comprendre, qu’il essaie de les intégrer en fonction de son propre vécu pour ensuite se créer une représentation mentale de ce que l’on a voulu dire.

Des mots, des phrases ont certes été perçus mais leur sens n’a pas été identique pour l’émetteur et le récepteur. D’un côté comme de l’autre, les sources de déformations et de distorsions sont multiples et comme nous négligeons le plus souvent de nous enquérir de ce que l’autre a compris, nous vivons régulièrement dans des mondes parallèles. Ce n’est qu’en cherchant à percevoir ce que l’autre a réellement compris et en comparant les expériences personnelles de chacun face à un même sujet que l’on peut commencer à communiquer. Pas avant !

Dans notre rapport à l’autre, nous devons abandonner l’idée d’une réalité unique et comprendre la communication comme un partage d’expérience et non comme un échange d’informations.

Chacun fabrique l’autre par projection. Il s’en suit un décalage qui peut devenir abyssal. La projection peut être positive ou négative se faire par idéalisation ou par rejet. Dans les deux cas, ne pas en être conscient engendre une bonne partie de nos problèmes relationnels.

En réalité, il importe moins de savoir ce que pense, ce que dit quelqu’un que pourquoi il le pense, il le dit. Les désaccords peuvent faire peur et il est très confortable d’être d’accord, les similitudes rassurent mais ça ne sert à rien. Chacun a de bonnes raisons de dire ce qu’il dit en fonction de son vécu. On s’enrichit mutuellement au contact du vécu de l’autre. Rejeter les divergences, chacun prouvant qu’il a raison et l’autre tort, rend les relations difficiles, voire même inutiles.

Il y a trois règles pour construire une relation :

  1. Parler de son ressenti…

    Lorsque l’on dialogue, nous n’avons pas à juger le comportement de l’autre, la règle d’or consiste à exprimer ce que l’autre provoque en nous, ce que nous ressentons vis-à-vis de son attitude.

  2. Partager des expériences…

    On communique véritablement quand on partage des expériences personnelles, pas quand on transmet des informations.

    Si nous n’apprenons rien de nouveau sur l’autre ou sur nous-même dans une discussion, ou que pire encore notre seul but est de persuader l’autre qu’il a tort, nous ne communiquons pas, nous transmettons des informations qui ne peuvent que susciter le rejet de quelqu’un de différend et l’approbation de quelqu’un de similaire.

    Une expérience est unique ; elle appartient à celui qui en fait part et à personne d’autre, jusqu’à ce que l’interlocuteur en saisisse le caractère spécifique. Il est donc important pour faire passer notre message d’expliquer simultanément d’où provient notre avis et sur quelle expérience nous nous fondons car soit notre discours devra être décodé puis interprété, soit il sera associé à des images, des émotions ou représentations personnelles qui peuvent se révéler différentes des nôtres.

    Les mots, les phrases sont certes perçus mais leur sens n’est pas identique pour l’émetteur et le récepteur. La transmission de notre pensée subit plusieurs déformations :

    • Une idée ou un ressenti qui passe dans notre conscience est d’abord traduit en mots,
    • Communiqués à notre interlocuteur, ce dernier comprend, filtre les mots comme il peut et les retraduit en idées ou ressentis,
    • Il s’en crée pour finir une représentation mentale qu’il intègre en fonction de son propre vécu.

    À défaut d’expériences communes, nous essayons de construire la situation dans notre imagination.

  3. Réaliser qu’il y a autant de réalités différentes que d’individus…

    Cela signifie que la plupart des conflits sont aussi vains qu’inutiles.

    Comme nous négligeons de nous enquérir de ce que l’autre comprend, nous vivons régulièrement dans des mondes parallèles. Il nous appartient de choisir si nous préférons résister face à des manières différentes de fonctionner ou développer la liberté de découvrir d’autres façons de penser.

    CHANGER D’ALTITUDE – Bertrand PICCARD – Octobre 2014

Développer in situ, c’est enfiler le vêtement de travail de l’utilisateur, celui du responsable de l’entité métier et surtout celui de ses gestionnaires :

  • pour vivre la problématique dans sa réalité,
  • pour structurer le métier d’après son mode d’organisation,
  • pour découvrir ce que l’utilisateur et ses gestionnaires ne savent pas qu’il savent.

La solution : Dès lors que le développeur et l’utilisateur ont le même objectif, il n’y a pas de raison de ne pas aboutir. La solution, c’est de supprimer les intermédiaires, de se rapprocher le plus possible de l’utilisateur jusqu’à développer dans son entité métier et de s’approprier la problématique de gestion. Les responsabilités ne sont pas diluées, le développeur assume seul son informatisation.

Mais comment s’y prendre ?… s’interrogent le petit oiseau et le petit poisson qui s’aiment d’amour tendre…

Un projet

Développer « in situ » c’est un projet à prospecter, à organiser, à construire, et l’administration offre un terrain de jeu idéal. Cela commence par la prospection d’un sujet porteur, d’une problématique de gestion particulière, rassemblant deux critères favorables :

  • une situation en difficulté, à l’agonie, une cause complètement désespérée donc potentiellement en recherche de solution,
  • et un utilisateur « qui vaut le coup », qui s’investit dans son domaine et semble prêt à jouer le jeu.

Contrairement à ce qui se pratique habituellement, la prise de contact est une initiative du développeur. L’approche prend la forme d’une rencontre opportune et le contact est d’autant plus aisé que le développeur est fonctionnaire avant d’être informaticien.

Après accord tacite, il reste à concrétiser « l’intrusion » dans l’entité métier. Cela peut être immédiat comme demander six mois, un an, voire davantage. L’administration offre un panel de possibilités comme le détachement, la mise à disposition, le concours administratif. L’installation pure et simple dans un service gestionnaire de la même entité administrative n’est pas forcément la démarche la plus simple, ni la plus rapide. Bien qu’il y ait eu accord tacite, l’utilisateur peut mettre un certain temps à lâcher prise, sans doute par peur de l’inconnu. Pour le développeur, ce n’est alors qu’une question de patience ; une problématique en grande difficulté s’enfonce inéluctablement jusqu’à atteindre son point de rupture.

Développer in situ, donc pour l’informaticien, s’extraire du service informatique, c’est se marginaliser au sein de l’entreprise structurée fonctionnellement, c’est générer fatalement des réactions, de la part du responsable de l’informatique, des collègues informaticiens, de la direction, du responsable du service gestionnaire, des gestionnaires.

L’affectation officielle du développeur dans une entité informatique reste toutefois une constante. La raison est double :

  • La première raison est financière car une prime informatique dépendant du grade est liée à l’affectation dans une structure informatique. Cette prime est dite « programmeur » pour un grade de catégorie B, et « analyste » pour un grade de catégorie A. La prime n’a rien à voir avec la fonction réelle. Ainsi, il n’existe pas de prime de « chef de projet ». Cette ambiguïté permet à un « programmeur » ou un « analyste » d’exercer la fonction générique de « développeur ».
  • La deuxième raison a tout simplement pour objectif de responsabiliser l’entité informatique quant-aux développements réalisés. Développer in situ se fait en toute transparence, ce n’est pas développer sur le tas, hors système, avec des objectifs personnels, faire de la « perruque » comme l’on disait à l’époque.

Une aventure

En développant « in situ », le développeur démystifie la création du logiciel, les gestionnaires comprennent très vite qu’il s’investit pour les aider et leur participation lui est toute acquise. Une aventure collective est en train de se construire.

Une URL=”https://fr.wikipedia.org/wiki/Force_opérationnelle”]task force[/URL] ou force opérationnelle se constitue de façon informelle. Les gestionnaires qui sont finalement autant de chefs de projet y gagnent un outil performant, fait sur mesure et le développeur y gagne sa liberté, le plaisir de créer, la satisfaction d’être utile, de relever divers challenges.

Pour le développeur, c’est une opportunité unique d’apprendre, d’être confronté à des points de vue différents, à des zones de l’entreprise, à des collègues et à des compétences.

Chaque projet est une aventure à risques avec sa période d’inconfort, son lot de surprises agréables et désagréables. C’est une aventure qui doit être vécue comme telle, dans une atmosphère d’excitation, d’expérimentation et d’urgence.

Cela suppose d’être libre de ses mouvements et dans sa tête, de penser par soi-même, de réfléchir et non de s’appuyer sur des recettes ; cela suppose d’avoir cherché et construit sa propre vérité, d’être autonome, pluridisciplinaire, de s’engager, de prendre des risques, d’adopter une véloce attitude.

Anecdote :

L’administration ne prévoit pas l’installation d’un informaticien « électron libre » dans une entité métier. Cela oblige tout le monde à s’adapter, à commencer par mon chef hiérarchique qui n’a pas réalisé les conséquences de ce qui était pourtant son initiative à l’origine…

Le jour où il m’a vu partir m’installer chez les gestionnaires :

Tu vas où ?

Et bien, je vais développer l’application pour la Formation Continue, c’est bien ce qu’on avait dit, non ?

Mais tu vas revenir ?

Pas avant un bon moment en tout cas. Je ne sais pas du tout ce qui m’attend…

Je suis parti 17 ans.

________________________________________

Quand nous arrivions à nous rencontrer :

J’ai trois ou quatre fiches de paie à te donner. Ça veut dire qu’on ne s’est pas vu depuis trois ou quatre mois.

Ça va… Tu supportes toujours d’être corvéable à merci ?

Je ne vis pas une corvée mais la situation de développement idéale que j’attends depuis que je développe. J’ai fait le pari que le budget allait finir par être débloqué. Tu ne le sais pas mais pour ça, j’ai décliné une offre très intéressante du Conseil Général et patienté un an.

________________________________________

Pour le développeur comme pour le responsable de l’entité métier, c’est compliqué… Humainement, ce n’est déjà pas évident, mais il faut encore trouver l’espace de travail et aménager cet espace.

Nous avions le même grade administratif et j’organisais son métier en m’intéressant davantage à ses gestionnaires qu’à lui-même. S’installer dans son environnement implique de créer son propre espace de travail, généralement dans un endroit insolite. Évidemment, ce mode de fonctionnement impacte la vie familiale et personnelle mais c’est le prix à payer de l’autonomie et de la liberté.

________________________________________

Constatant la réussite de la démarche « informaticien dans l’entité métier », la direction (Secrétaire Général) suggère l’installation de chaque informaticien responsable d’une application dans l’entité métier. L’initiative a eu pour effet de provoquer une levée de bouclier de la part des collègues informaticiens et de détériorer nos relations. Transférer le responsable d’une application (nationale) développée par d’autres dans l’entité métier ne change en rien l’application elle-même. La relation « informatisation réussie / développent in situ » n’a pas été perçue.


Une task force (force opérationnelle)

Il est institué dans l’applicatif un « Générique » qui recense toutes les personnes ayant participé à la réalisation de l’applicatif.
L’application est considérée comme une œuvre de l’équipe ad hoc, constituée :

  • du développeur,
  • de l’utilisateur responsable de l‘entité métier (maître d’ouvrage),
  • du ou des chefs de service,
  • des gestionnaires.

Comme pour un film, le Générique cite toutes les personnes ayant participé à l’élaboration de l’œuvre. Avec le temps, la composition de l’équipe évolue, le Générique est une forme de reconnaissance des apports de chacun, et la concrétisation en quelque sorte de l’appropriation de l’applicatif par ses utilisateurs. C’est le moyen d’intéresser, de motiver une nouvelle recrue intégrant l’équipe car il est attendu de sa part qu’elle apporte sa contribution au logiciel.

Le développement APL-AML n’est pas seulement une aventure que pour le développeur. Tous les contributeurs vivent la même aventure exaltante. À chaque nouvelle rentrée, il peut toujours y avoir quelques mutations mais globalement, la façon de travailler fidélise les gestionnaires.

Une gestionnaire a renoncé deux années de suite au bénéfice d’un concours au prétexte qu’elle ne trouverait jamais ailleurs une telle ambiance. Il a fallu beaucoup de persuasion pour qu’elle finisse par accepter une affectation dans une autre administration. Beaucoup d’entre-elles se reçoivent et gardent contact via les réseaux sociaux.

Générique Formation Continue :

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
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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
┌──────────┬───────────────────────────────────────────────────────────────────┐
│ Services │                        GÉNÉRIQUE OSMOSE                           │
├──────────┼─────────────────────────────────┬─────────────────────────────────┤
│          │                                 │                                 │
│   DI     │         IFA2377                 │ Chef de projet - Développeur    │
│          │                                 │                                 │
├──────────┼─────────────────────────────────┼─────────────────────────────────┤
│          │                                 │                                 │
│   CAF    │       Jean-Paul B.              │ RAF                             │
│   CAF    │         Thierry B.              │ RAF                             │
│   CAF    │           Serge C.              │ RAF                             │
│   CAF    │     Jean-Pierre H.              │ RAF                             │
│          │                                 │                                 │
├──────────┼─────────────────────────────────┼─────────────────────────────────┤
│          │                                 │                                 │
│   CAF    │           Annie L.              │ Collaboratrice CAF              │
│   CAF    │        Patricia C.              │ Collaboratrice CAF              │
│   CAF    │        Jocelyne D.              │ Collaboratrice CAF              │
│   CAF    │    Marie-Hélène LE M.           │ Collaboratrice CAF              │
│   CAF    │          Arnaud T.              │ Collaborateur  CAF-Webmaster    │
│   CAF    │            Yves C.              │ Collaborateur  CAF-Informaticien│
│   CAF    │         Gilbert S.              │ Collaborateur  CAF              │
│   CAF    │       Jean-Marc R.              │ Collaborateur  CAF              │
│   CAF    │     Jean-Michel LE M.           │ Collaborateur  CAF              │
│   CAF    │         Patrice G.              │ Collaborateur  CAF              │
│   CAF    │        Philippe M.              │ Collaborateur  CAF              │
│          │                                 │                                 │
├──────────┼─────────────────────────────────┼─────────────────────────────────┤
│          │                                 │                                 │
│   IUFM   │            Yves A.              │ Directeur du Centre             │
│          │                                 │ de Formation Continue           │
│          │                                 │                                 │
├──────────┼─────────────────────────────────┼─────────────────────────────────┤
│          │                                 │                                 │
│   CAFA   │            Lila A.              │ Gestionnaire                    │
│   CAFA   │         Sabrina A.              │ Gestionnaire                    │
│   CAFA   │       Jeannicka A.              │ Gestionnaire                    │
│   CAFA   │         Arielle A.              │ Gestionnaire                    │
│   CAFA   │         Candice B.              │ Gestionnaire                    │
│   CAFA   │         Barbara B.              │ Gestionnaire                    │
│   CAFA   │      Jacqueline B.              │ Gestionnaire                    │
│   CAFA   │       Françoise B.              │ Gestionnaire                    │
│   CAFA   │         Danièle È.              │ Ingénieur de formation          │
│   CAFA   │         Chantal F.              │ Gestionnaire                    │
│   CAFA   │            Yves G.              │ Gestionnaire                    │
│   CAFA   │       Christian J.              │ Chef de service                 │
│   CAFA   │        Thu-Loan L.              │ Gestionnaire                    │
│   CAFA   │          Joëlle L.              │ Chef de service                 │
│   CAFA   │        Isabelle L.              │ Gestionnaire                    │
│   CAFA   │       Catherine M.              │ Gestionnaire                    │
│   CAFA   │ Marie-Christine P.              │ Gestionnaire                    │
│   CAFA   │           David P.              │ Gestionnaire                    │
│   CAFA   │       Stéphanie S.              │ Gestionnaire                    │
│   CAFA   │          Nicole S.              │ Gestionnaire                    │
│   CAFA   │         Martine T.-B.           │ Gestionnaire                    │
│   CAFA   │           Lydie V.              │ Gestionnaire                    │
│   CAFA   │          Sylvie V.              │ Gestionnaire                    │
│   CAFA   │         Chantal V.              │ Gestionnaire                    │
│   CAFA   │        Virginia Z.              │ Gestionnaire                    │
│          │                                 │                                 │
├──────────┼─────────────────────────────────┬─────────────────────────────────┤
│          │                                 │                                 │
│   FCE2   │           Nadia A.              │ Gestionnaire                    │
│   FCE2   │         Nassima A. M.           │ Gestionnaire                    │
│   FCE2   │      Marie-Luce B.              │ Chef de division                │
│   FCE2   │        Mireille B.              │ Gestionnaire                    │
│   FCE2   │         Colette B.              │ Gestionnaire                    │
│   FCE2   │        Stéphane B.-C.           │ Gestionnaire                    │
│   FCE2   │         Valérie B.              │ Gestionnaire                    │
│   FCE2   │            Lada B.              │ Gestionnaire                    │
│   FCE2   │       Angélique C.              │ Gestionnaire                    │
│   FCE2   │        Claudine C.              │ Gestionnaire                    │
│   FCE2   │        Caroline C.              │ Gestionnaire                    │
│   FCE2   │        Huguette C.              │ Gestionnaire                    │
│   FCE2   │         Martine C.              │ Gestionnaire                    │
│   FCE2   │           Frank D.              │ Gestionnaire                    │
│   FCE2   │      Christiane D.              │ Gestionnaire                    │
│   FCE2   │         Colette D.              │ Gestionnaire                    │
│   FCE2   │      Frédérique D.              │ Gestionnaire                    │
│   FCE2   │        Blandine F.              │ Gestionnaire                    │
│   FCE2   │       Élisabète F.              │ Gestionnaire                    │
│   FCE2   │        Laurence G.              │ Gestionnaire                    │
│   FCE2   │         Romuald G.              │ Gestionnaire                    │
│   FCE2   │        Séverine H.              │ Gestionnaire                    │
│   FCE2   │            Rebh H.              │ Gestionnaire                    │
│   FCE2   │   Thi Anh Hoang H.              │ Gestionnaire                    │
│   FCE2   │        Sophonie J.              │ Secrétaire                      │
│   FCE2   │    Marie-France K.              │ Secrétaire                      │
│   FCE2   │          Joëlle K.              │ Gestionnaire                    │
│   FCE2   │      Christiane L.              │ Gestionnaire                    │
│   FCE2   │        Florence LE D.           │ Gestionnaire                    │
│   FCE2   │       Christine L.              │ Gestionnaire                    │
│   FCE2   │           Annie L.              │ Gestionnaire                    │
│   FCE2   │         Magalie M.              │ Gestionnaire                    │
│   FCE2   │         Laurent M.              │ Gestionnaire                    │
│   FCE2   │      Rose-Marie M.              │ Gestionnaire                    │
│   FCE2   │        Béatrice M.              │ Gestionnaire                    │
│   FCE2   │          Karine M.              │ Gestionnaire                    │
│   FCE2   │       Sébastien M.              │ Gestionnaire                    │
│   FCE2   │            Paul O.              │ Chef de service                 │
│   FCE2   │        Marylène P.              │ Gestionnaire                    │
│   FCE2   │       Micheline R.              │ Gestionnaire                    │
│   FCE2   │       Geneviève R.              │ Chef de service                 │
│   FCE2   │        Patricia S.              │ Gestionnaire                    │
│   FCE2   │        Béatrice T.              │ Gestionnaire                    │
│   FCE2   │          Magali T.              │ Gestionnaire                    │
│   FCE2   │          Karine T.              │ Gestionnaire                    │
│   FCE2   │         Josette T.              │ Gestionnaire                    │
│   FCE2   │         Héloïse T.              │ Gestionnaire                    │
│   FCE2   │        Danielle Q.              │ Gestionnaire                    │
│   FCE2   │             Ève R.              │ Gestionnaire                    │
│   FCE2   │ Marie-Dominique V.              │ Gestionnaire                    │
│   FCE2   │          Élodie V. P.           │ Gestionnaire                    │
│   FCE2   │          Sylvie V.              │ Gestionnaire                    │
│   FCE2   │        Nathalie W.              │ Gestionnaire                    │
│          │                                 │                                 │
└──────────┴─────────────────────────────────┴─────────────────────────────────┘

Générique Examens-Concours :

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
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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
┌──────────┬───────────────────────────────────────────────────────────────────┐
│ Services │                        GÉNÉRIQUE Ex&Co                            │
├──────────┼─────────────────────────────────┬─────────────────────────────────┤
│   SDI 24 │         IFA2377                 │ Chef de projet - Développeur    │
│   SDI 25 │         Martine N.              │ Correspondante Versailles       │
├──────────┼─────────────────────────────────┼─────────────────────────────────┤
│  SECA    │          Romina A.              │ Gestionnaire                    │
│  SECA    │    Marie-Claude A.              │ Gestionnaire                    │
│  SECA    │          Didier B.              │ Gestionnaire                    │
│  SECA    │          Karine B.              │ Gestionnaire                    │
│  SECA    │        Isabelle B.              │ Gestionnaire                    │
│  SECA    │       Stéphanie B.              │ Gestionnaire                    │
│  SECA    │         Laurent C.              │ Chef de service                 │
│  SECA    │          Mylène C.              │ Gestionnaire                    │
│  SECA    │      Christelle C.              │ Gestionnaire                    │
│  SECA    │          Sylvie D.              │ Gestionnaire                    │
│  SECA    │          Yvette D.              │ Gestionnaire                    │
│  SECA    │           David F.              │ Gestionnaire                    │
│  SECA    │        Aurélia  F.              │ Gestionnaire                    │
│  SECA    │          Nadine F.              │ Gestionnaire                    │
│  SECA    │         Valérie F.              │ Gestionnaire                    │
│  SECA    │          Hélène G.              │ Gestionnaire                    │
│  SECA    │       Catherine G.              │ Gestionnaire                    │
│  SECA    │         Magalie G.              │ Gestionnaire                    │
│  SECA    │         Thierry GROB            │ Gestionnaire                    │
│  SECA    │          Lionel H.              │ Gestionnaire                    │
│  SECA    │         Tabatha H.              │ Gestionnaire                    │
│  SECA    │          Sabine J.              │ Gestionnaire                    │
│  SECA    │            Éric L.              │ Gestionnaire                    │
│  SECA    │          Sandra LE G.           │ Gestionnaire                    │
│  SECA    │           Alice L.              │ Gestionnaire                    │
│  SECA    │        Isabelle L.              │ Gestionnaire                    │
│  SECA    │         Sylvie  L.              │ Gestionnaire                    │
│  SECA    │          Myriam L.              │ Gestionnaire                    │
│  SECA    │          Régine M.              │ Gestionnaire                    │
│  SECA    │         Monique M.              │ Chef de service                 │
│  SECA    │         Laurent M.              │ Gestionnaire                    │
│  SECA    │          Régine M.              │ Gestionnaire                    │
│  SECA    │      Bernadette M.              │ Gestionnaire                    │
│  SECA    │        Philippe M.              │ Gestionnaire                    │
│  SECA    │          Agathe M.-E.           │ Gestionnaire                    │
│  SECA    │          Sophie N.              │ Gestionnaire                    │
│  SECA    │          Sophie N.              │ Gestionnaire                    │
│  SECA    │        Frédéric P.              │ Gestionnaire                    │
│  SECA    │         Florent P.              │ Gestionnaire                    │
│  SECA    │        Delphine P.              │ Gestionnaire                    │
│  SECA    │         Pascale P.              │ Gestionnaire                    │
│  SECA    │      Christophe R.              │ Gestionnaire                    │
│  SECA    │         Thierry R.              │ Gestionnaire                    │
│  SECA    │         Nicolas R.              │ Gestionnaire                    │
│  SECA    │         Raphaël R.              │ Gestionnaire                    │
│  SECA    │           Tania S.              │ Gestionnaire                    │
│  SECA    │       Joséphine S.              │ Gestionnaire                    │
│  SECA    │        Philippe S.              │ Gestionnaire                    │
│  SECA    │           Hervé T.              │ Gestionnaire                    │
│  SECA    │       Véronique T.              │ Gestionnaire                    │
│  SECA    │           Lydie V.              │ Gestionnaire                    │
└──────────┴─────────────────────────────────┴─────────────────────────────────┘

Développer au pied levé

Classiquement, le point de départ d’un développement pragmatique d’applicatif (Au Pied Levé) est le challenge. Plus le challenge présente de risques, de difficultés, un caractère urgent voire vital, plus il a de chances d’être « accepté ». Accepté par le responsable du service informatique, le chef du service de gestion, les gestionnaires eux-mêmes. Accepté, parce que les raccourcis qu’il implique bousculent quelque peu l’organisation fonctionnelle de l’entreprise et chahute la hiérarchie, laquelle compte tenu de la situation, n’a d’autre alternative que de s’en remettre entièrement, non sans quelque appréhension, à l’informaticien développeur qui devient alors l’homme providentiel.

Ainsi, le responsable informatique doit accepter les risques inhérents à cette démarche, comme budgéter un projet sans garantie tangible de résultat, laisser se poursuivre un développement avec l’incertitude de sa pérennité, admettre l’installation à demeure de l’informaticien développeur dans le service de gestion. De son côté, l’utilisateur, à savoir le responsable de l’entité métier, doit vivre au quotidien la présence de l’intrus qui considère davantage ses gestionnaires que lui-même. Quant aux gestionnaires, leur confiance et leur collaboration sont à priori acquises dans la mesure où ils sont demandeurs. Il suffit d’entretenir cette confiance par une écoute attentive de leurs besoins, une réactivité sans faille, une grande disponibilité, une très grande disponibilité. A ce sujet, l’adhocratie dit ceci :

« La contribution à des équipes ad hoc lorsqu’elle s’avère devoir être très intense ne se limite pas à 40 heures par semaine, mais suppose de travailler autant que nécessaire. Certains utilisent l’expression de “double plein temps” »

Après des prémices plus ou moins longs, coordination, recherche d’un budget, contact avec des fournisseurs, installation d’un serveur, installation du développeur dans l’entité métier, etc., la situation généralement critique de la problématique de gestion impose un démarrage immédiat de l’ordre de la semaine, voire moins. Le challenge, c’est le développement au pied levé et à main levée.

Au démarrage, 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.

Personne n’y croit vraiment mais ça marche. Le challenge se vit seul, sans l’expliquer à la hiérarchie arrimée à ses certitudes.

Une démarche personnelle, individuelle ?

La démarche est indéniablement personnelle mais pas impérativement individuelle. Le cas s’est présenté de démarrer une informatisation en binôme. L’expérience eut pu être intéressante et répondre à beaucoup de questions mais a tourné court après seulement trois jours. Pas d’explication du co-développeur, il n’est tout simplement pas réapparu le 4ème jour.

Il y a beaucoup d’avantages à développer seul, il n’y a pas de perte de temps en réunions, en coordination ; la réalisation est homogène, riche en synergie. Pas d’étude préalable, pas de cahier des charges, pas de MCD, de MCT… Rien ! Le démarrage est quasi immédiat ; selon le contexte : un jour, trois jours…

Une informatisation au pied levé ne s’envisage semble-t-il que dans un contexte désespéré. Il n’y a pas d’obligation mais quel utilisateur accepterait l’informatisation de son entité métier sans garanties, s’il ne se trouvait pas dans une impasse, sans autre choix que de s’en remettre les yeux fermés au développeur.

Chef d’orchestre sans partition ouverte, l’informaticien providentiel développe in situ et « just in time ». Son challenge (low cost, high speed, high quality) s’inscrit dans une approche basée sur l’investigation in situ, l’intuition et le pragmatisme et non sur la technicité méthodique.

Ce type de développement s’apparente à du prototypage d’application, du prototypage de luxe mais du prototypage qui reste du jetable… Même si ça dure 17 ans. L’idée, ce n’est pas de créer du définitif très beau, très sophistiqué, mais de résoudre une problématique immédiatement, avec des moyens simples et d’aboutir au final à la création d’une documentation à postériori qui fasse office de documentation utilisateur, de support de formation et surtout de cahier des charges pour un développement ultérieur par une méthode classique Top-Down. On n’est plus alors dans l’inconnu (effet tunnel), ni dans l’urgence.

Retours d’expérience :

1990 : Formation Continue des Personnels Enseignants (FCPE)

L’entité administrative se situe à l’Annexe, un bâtiment séparé du rectorat par un petit jardin public. Pas encore relié par la fibre optique au système central GCOS 64 du rectorat, l’outil informatique local développé en B.A.L. sous Prologue par un enseignant de Jussieu est devenu complètement obsolète (ordinateur, système d’exploitation, langage, application). Pour parer à l’instabilité du système qui perd facilement ses index, les gestionnaires font des sauvegardes toutes les demi-heures.

1991 : Sans budget, la division informatique qui n’assume que les applications nationales sur son ordinateur central, n’est d’aucun secours. Le problème est insoluble ; un an se passe persillé de réunions pour élaborer sans grande conviction, une étude préalable et un cahier des charges. D’autres solutions adoptées par certaines Académies sont étudiées mais sans y donner suite.

L’espoir d’une récupération de l’application Informix développée à Lille tourne court car un problème conceptuel la condamne sans appel : Les candidatures à une formation, limitées à deux, sont traitées comme attributs dans l’entité « Personnes » au lieu de constituer une entité « Candidatures » à part entière. Ce choix conceptuel conduira d’ailleurs Lille à redévelopper entièrement son application en 4GL.

Une application développée sous Unix avec le SGBD/R Informix s’avère toutefois la plus conforme aux orientations prises par le Ministère. Un appel d’offres en ce sens permet d’avoir une indication du budget nécessaire. Un fournisseur est pressenti et se tient prêt à intervenir. Pendant ce temps, Les candidatures s’accumulent inexorablement.

Début mai, l’impasse budgétaire se débloque miraculeusement, on oublie tout, l’étude préalable, le cahier des charges, l’application Informix de Lille… En trois jours, il faut assimiler l’essentiel d’Unix-Informix, créer un embryon de Base de Données et un écran de saisie des candidatures. Ultime péripétie, le deuxième informaticien qui suit l’affaire depuis le début « démissionne ».

1992 : Examens et concours (Ex&Co)

Fin d’année budgétaire (Novembre 1991), le Centre Académique de Formation de l’Administration (CAFA) dispose d’un reliquat budgétaire conséquent. Mis en confiance par l’informatisation réussie de la FCPE, il est décidé d’en faire bénéficier le service des Examens-Concours qui travaillent quasi manuellement et s’attend à une augmentation importante des candidatures. Alternant des périodes d’activité intense et stressante avec des périodes de désœuvrement, le service est le vilain petit canard, consommateur de budget (location de salles, sous-traitance) et d’énergie (membres du jury) pour un bénéfice (recrutement) peu perceptible.

À cause de son inventaire, le fournisseur ne peut livrer le serveur commandé que fin janvier. Les premiers concours sont déjà ouverts et les candidatures s’empilent sur les bureaux. Première semaine de février : 4 jours sont nécessaires pour installer le serveur, Unix et Informix. 5ème jour : importation des développements FCPE (la structure de la Base de Données (MCD et MCT) est pratiquement identique), création d’un menu, des paramètres applicatifs et des premiers écrans de saisie. Installation d’un poste de travail sur chaque bureau pendant le week-end. Lundi matin, rapide initiation aux raccourcis clavier et les gestionnaires se lancent.

L’expression « Au pied levé » signifie ne pas avoir le temps de se préparer, ou que quelque chose se fait ou se décide à l’improviste. Cette expression existe depuis le XVème siècle et vient du fait que lorsqu’on a envie d’aller quelque part, on lève d’abord un pied puis l’autre. Si au cours de cette action, quelqu’un nous surprend à l’improviste, sans avoir le temps de nous préparer à sa demande, il nous apercevra le pied levé. A ses débuts, l’expression n’était employée que lorsque l’on s’adressait à quelqu’un au moment où il s’apprêtait à partir, c’est-à-dire lorsqu’il avait le pied levé ! Puis au fur et à mesure, l’expression s’est généralisée à toutes les personnes qui exécutent quelque chose à l’improviste ou sans disposer du temps nécessaire pour préparer ce qu’on lui demande. Au milieu du XVème siècle, l’expression employée était « à pied levé » puis au milieu du XVIème siècle elle est devenue « au pied levé ».

I-1. Les règles de conception

► I-1.1. Développer in situ, au pied levé
▼ I-1.2. Développer à main levée

Aller à la source
Author: APL-AML