Commentaires

■ Expérience d’apprentissage APL-AML

■ ■ ■ SOMMAIRE ■ ■ ■

AVANT-PROPOS

1. Prédispositions
2. Détermination
3. Autoformation
4. Conclusion

---

■ AVANT-PROPOS

Envoyé par LittleWhite

Quelle est la meilleure méthode pour apprendre la programmation ? Ici, on parle bien de programmation (ou autrement dit, la logique) et non de l'apprentissage d'un langage en particulier.

N'hésitez pas à partager votre expérience d'apprentissage, ou encore, de dire comment vous, vous auriez aimé apprendre la programmation.

45 votants, 21 intervenants et seulement deux expériences d’apprentissage de la programmation par des autodidactes. En fait, leurs témoignages relèvent davantage de leur apprentissage des langages que de celui de la programmation proprement dite. Globalement, on peut dire que Programmation = Codage.

Envoyé par walfrat

Personnellement, j'avais bidouillé gentiment PHP en autodidacte et même fais un peu de C, je m'étais arrêté au pointeur.

Mon niveau de programmation ne volait pas donc haut. Il m'a pourtant été d'une grande aide une fois en BTS info & réseau puis INSA.

Pourquoi ? Je m'étais déjà suffisamment payé de boucles, de petits tests de logique, d'erreurs du débutant, que quand j'ai commencé l'info en BTS j'étais "fluent" en écriture de code. Tout ce que j'avais fait c'était un site web pour une guile dans un jeu où l'on pouvait s'authentifier et saisir un formulaire pour remplir des tableaux.

Envoyé par Fagus

J'ai appris tout seul, et on m'avait conseillé le C++ à l'époque où c'était un mélange de C++ et de C et où il n'y avait pas vraiment de cours gratuits en ligne, et où les RAD étaient tous payants. J'ai commencé par un petit livre poche de 350 pages, mais avec ça je ne pouvais rien faire en dehors d'un programme en console basique et très décevant, et les codes en ligne à cause du C mélangé n'étaient pas clairs.

J'ai avalé un livre énorme (1-2kg) de C/C++, d’algorithmie, de notions de machine bas niveau. Gros coup de cœur avec le C. J'ai beaucoup appris, mais à la fin, pour faire des GUI, il m'envoyait vers les MFC à la main ou des outils payants. C'était vraiment une expérience punitive et programmer en C n'est pas très productif pour un débutant à réinventer l'eau tiède et à boucher les fuites de mémoire.

Ce sont les langages de script à la basic qui m'ont sauvé. J'en ai appris un en un week-end avec cette base et avec un environnement intégré et un accès pré-mâché aux API windows tout était si simple et la productivité énorme, mais ça devenait galère sans programmation objet ni multithread bien fichu pour quelque chose de plus qu'un script.

Python m'a sauvé une 3e fois avec sa polyvalence et haute productivité avec la documentation et les lib énormes, d'autant plus que j'ai pu beaucoup bénéficier du C/C++ conceptuellement (typage optionnel du python, POO, culture, etc.)

Il n’y est question ni de méthodologie, ni d’acquisition d’un savoir-faire, ni de logique, de réflexion personnelle, conceptuelle, analytique.

Le discours est essentiellement orienté hard skills : pointeur, boucles, code, guile, C, C++, PHP, GUI, MFC, langage de script, Basic, API Windows, programmation objet, multithread, Python, lib, typage, POO.

Il semble que l’apprentissage de la programmation soit un processus difficile à exprimer du point de vue de la logique, des soft skills, la partie immergée de l’iceberg « développement ».

---

■ § 1. Expérience d’apprentissage

Ce que je retiens de mon apprentissage de la programmation tient en trois mots : prédispositions, détermination, autoformation.

■ § 1.1. Prédispositions

Prédisposition, vocation ou syndrome psychologique

Envoyé par Claude40

La « vocation » : Il faut se lancer dans la programmation, non pas parce que c’est réputé être bien payé, mais parce que vous sentez que vous allez y prendre du plaisir.

L’esprit « Sherlock Holmes » : Vous avez un certain goût et une certaine propension à résoudre les problèmes, à trouver les solutions, à détecter les anomalies et leurs causes. C’est une disposition d’esprit qui n’est pas donnée à tout le monde. Vous gagnerez du temps en mise au point de vos programmes.

On peut posséder certaines dispositions pour l’art, la peinture, la musique, le chant… et l’informatique.

Mon cerveau génétiquement câblé « logique, perfectionniste, créatif, empathique » était connu de toute la famille. Un soir, mon cousin passe me voir et m’annonce :

- « Je sais ce que tu vas faire comme métier : programmeur »…

C’était en 1966, j’avais 18 ans. Cette année-là, l'Académie française consacre officiellement l'usage du mot “ Informatique ” pour désigner la « science du traitement de l'information ».

Oubliées mes trois années d’enseignement technique à dessiner des vues de dessus à l’encre de chine, à mémoriser la composition des alliages, les rondelles Grower. Oubliées les heures d’atelier à fraiser, tourner, forer et limer le petit poil au centre de mes objets d’art, tantôt une clavette, tantôt un trusquin.

■ § 1.2. Détermination

Après le collège, mon père m’a dit :

« tu sais ce qu’il te reste à faire… »

Étant l’ainé, j’ai supposé que je devais aller travailler. Et c’est comme ça que je me suis retrouvé O.S. en attendant le service militaire. Mon petit salaire presque entièrement donné à ma mère pour l’aider à faire vivre notre famille nombreuse, m’a quand même permis de suivre les cours par correspondance "Programmeur assembleur IBM 1401" dispensés par l’école privée EPSI.

Dans le même temps, j'ai fait la connaissance accidentelle d’une analyste chez IBM. "Accidentelle" parce qu’elle a maladroitement cabossé ma super Chambord sagement garée devant chez moi. En dédommagement, elle m’a proposé de faire saisir puis compiler mes exercices de cours à son travail. C’était impressionnant le nombre d’erreurs que signalait le compilateur. Mes premiers programmes datent donc de mi-1966-début 1967. Tout allait bien mais au moment de passer l’examen final, la France a eu besoin de moi.

L’EPSI proposait d’intervenir pour favoriser une affectation de ses élèves au service informatique de l’armée. Incorporé dans les parachutistes au 13ème RDP, il m’a été difficile psychologiquement de solliciter une intervention sans passer pour un dégonflé. In situ, il n’est pas facile de troquer son béret rouge pour un béret noir. Les deux derniers mois de mon service, nous étions quatre de la même classe à préparer les championnats de France de pentathlon militaire. Très privilégiés, nous logions dans un petit appartement d’un bâtiment du régiment très à l’écart. À l’écart de tout d’ailleurs, notamment de l’actualité. En dehors des entrainements, je révisais mes cours en vue de passer l’examen final dès mon retour à la vie civile. Pour une raison que nous ignorions, la date des championnats a été repoussée et il a été convenu que nous fassions deux mois de plus sous couvert d’une peine fictive de prison. Nous savions que le régiment était consigné mais nous ne savions pas pourquoi. Finalement, toute la classe 67 1B a été libérée en deux jours fin juin 68. Entre nous, nous discutions de ce que nous allions faire une fois rentrés chez nous. Lorsque je leur dévoilais mon projet d’être programmeur et leur expliquais en quoi cela consistait, cela les faisait bien rire et ils me rétorquaient que ce métier n’existait même pas.

De retour à la vie civile, je me suis évidemment retrouvé au chômage. Comme prévu avec 16 mois de retard, j’ai passé mon examen de "Programmeur assembleur IBM 1401" mais entre-temps, l’IBM 360 avait remplacé l’IBM 1401. Au chômage, j’ai pu suivre très rapidement les cours "Programmeur assembleur IBM 360". Au lieu de poster mes devoirs et attendre de recevoir le cours suivant, j’allais faire l’échange "devoirs contre prochain cours", directement chez EPSI.

Pédagogiquement, une formation par correspondance (cours écrits) n’est pas la même chose qu’une formation en présentiel (cours oraux). Les cours par correspondance obligent à s’impliquer davantage.

Compte tenu du contexte, les propositions d’emploi en informatique étaient rares. On trouvait quelques annonces en mécanographie classique. Puis j’ai eu la chance d’être embauché au service informatique d’une administration… comme opérateur-pupitreur. Surpris d’être convoqué pour un entretien, j’avais sans doute envoyé un CV dont je ne me souvenais plus. Bien plus que mes deux diplômes EPSI inutiles, mes états de service militaire ont dû favoriser mon embauche car à l’époque, pour intégrer l’administration, il y avait une enquête préalable de bonne moralité. Je me souviens avoir repéré des gendarmes roder près de chez moi et interroger les voisins. Mais peut-être me suis-je fait des idées ?

Lors de l’entretien pour ce poste d’opérateur-pupitreur, je n’ai surtout rien dit de mes activités sportives. La personne qui m’a embauché ne l’a appris que deux ans plus tard en lisant l’Équipe. Elle-même avait arrêté récemment sa carrière d'athlète et sans le savoir, nous étions du même club.

À mes débuts comme pupitreur, je pensais bien faire en essayant de mémoriser le processus d’initialisation de l’ordinateur. Le chef d’exploitation qui m’initiait m’a arrêté tout de suite en me disant :

- « Ne cherche pas à apprendre ce que tu dois faire mais comprends ce que tu fais. Certes pour démarrer il faut appuyer successivement sur Clear, Load, Run, mais mentalement tu dois comprendre qu’il faut d'abord initialiser la mémoire avant de charger le système puis l’exécuter. »

Bertrand PICCARD dit :

- « Apprendre à ne rien faire sans comprendre pourquoi on doit le faire. »

Le chef d’exploitation était un ancien garde forestier reconverti dans l’informatique car trop mal payé. Il me disait qu’il ne servait à rien que les garde-forestiers fassent grève car ça n’empêchait pas les arbres de pousser.

Je n’ai été intronisé « programmeur » que le 1er janvier 1971… Après deux ans à l’exploitation à travailler une semaine du matin, une semaine de l’après-midi et une semaine de nuit. La quatrième semaine était de repos mais la plupart du temps on remplaçait un collègue qui devait faire le matin ou la nuit. Du matin ou de nuit, nous assurions le week-end, soit deux fois 12 heures consécutives. Ces semaines faisaient 69 heures. Nous gagnions davantage que les programmeurs.

Les DUT informatiques datent de 1971. Avant cette date, les programmeurs se recrutaient à la faveur d’une batterie de tests psychotechniques censés révéler leurs capacités de réflexion et de logique. Le niveau d’études n’était pas un critère. Mon BEPC de 1964, Brevet des Collèges d’aujourd’hui, n’a pas été un handicap.

Dans le privé, les tests les plus courants étaient dits "Tests IBM". Je les ai passés plusieurs fois avec succès mais l’entretien final m’était fatal lorsque j’évoquais mes activités sportives de haut niveau.

Apparemment ce genre de loisir leur paraissait incompatible avec la profession. Pourtant la pratique d’un sport participe au formatage de notre réflexion. Deux à trois heures d’entrainement par jour, c’est deux à trois heures de travail mental, de réflexion complexe pour gérer son effort, la distance, les obstacles, le chronomètre, pour se situer dans un plan de progression annuel et pluriannuel. En compétition, s’ajoutent la maitrise du stress, de ses émotions, la gestion des opportunités, la capacité à passer d’un état mental extrême à un autre... Cette stratégie de flexibilité psychologique conduit le sportif à s’adapter en toutes circonstances et très rapidement, aux fluctuations permanentes des situations et du milieu, à switcher entre disponibilité et décision, entre vigilance et passage à l’action.

De son côté, l’administration recrutait ses programmeurs par concours de catégorie B "Secrétaire Administratif spécial programmeur". Mais auparavant il fallait être autorisé à concourir, c’est-à-dire avoir été admis à deux batteries de tests psychotechniques. Il n’était possible de passer ces tests qu’une seule fois. Échouer à ces tests signifiait envisager un autre métier. Conscient de l’enjeu, je les ai préparés comme pour une compétition, physiquement, psychologiquement et mentalement.

Les premiers tests dits "Tests PTT" étaient collectifs. Réunis dans une grande salle, chaque candidat avait sur sa table un cahier d’une quinzaine de pages. Un appariteur, juché sur une estrade, donnait le top départ pour tourner une page et faire l’exercice, puis le top fin d’exercice où l’on devait impérativement poser son stylo.

Admis aux premiers tests, les deuxièmes tests, individuels, se passaient face à un psychologue. Selon le candidat, ils pouvaient durer plus ou moins longtemps, jusqu’à facilement une heure. L’un de ces tests consistait à reconstituer un puzzle en 3D, en fait un parallélépipède rectangle composé de 9 pièces différentes peintes en noir. On fermait les yeux et quand on les rouvrait, les 9 pièces étaient éparpillées sur la table. On pouvait faire ce test deux voire trois fois de suite selon la méthode de reconstitution utilisée. J’en ai utilisé trois différentes, ce qui a déconcerté mon psychologue, à deux doigts de me proposer un quatrième essai pour cerner ce qui se passait dans mon cerveau.

Pour devenir programmeur, il fallait non seulement avoir certaines dispositions mais il fallait également être très déterminé. Admis aux tests, le concours lui-même se préparait par correspondance pendant un an. Les cours étaient assurés par le Ministère des Finances et un examen final délivrait un Certificat d’Aptitude aux Fonctions de Programmeur. Au concours administratif il y avait les épreuves classiques, dissertation ou résumé de texte et droit administratif, auxquelles s’ajoutait un programme COBOL. La réussite au concours permettait d’être titularisé.

Titularisé le 1er janvier 1971, la veille, je montais encore du papier sur l’imprimante et des bandes magnétiques sur les dérouleurs. Le lendemain, j’étais programmeur aux Études et mes nouveaux collègues étaient soit ingénieurs (ITR ou IGREF), soit professeurs de math. Je n’avais pour ma part qu'un Brevet de Parachutiste et seulement réussi des tests psychotechniques puis un concours administratif de catégorie B. J’avais 23 ans et la moyenne d’âge de notre entité informatique était de moins de 30 ans.

Anecdote : le 1er janvier 1971 parait « La méthode informatique » de Robert Mallet (texte fondateur de la méthode CORIG).

Tous découvraient l’informatique et s’étaient sans doute initiés à leur rôle de chef de projet et d’analyste par des stages chez le constructeur. Confrontés à ces nouveaux métiers, nous étions tous égaux et chacun apprenait de sa recherche personnelle. Bien que nous n’en fussions qu’aux balbutiements de l’informatique et qu’il n’exista pas de corps d’informaticiens, la hiérarchie administrative avait déjà cloisonné les fonctions de chef de projet, d’analyste et de programmeur.

Dans la dynamique de mai 68, les collègues se réunissaient de temps en temps dans un couloir pour refaire le monde. Il faut dire qu’aucune application ne donnait vraiment satisfaction aux utilisateurs. Ce cloisonnement « chef de projet/analyste/programmeur » était régulièrement contesté, pas seulement pour la méthode de développement mais également à cause de l’impossibilité d’être tantôt l’un, tantôt l’autre. Ce sont ces réunions contestataires qui ont inspiré ma démarche de développement.

Parmi mes collègues aux profils hétéroclites, bien trop occupés à apprendre leur nouveau métier, je me suis retrouvé livré à moi-même. Marginalisé dès le départ, je le suis resté durant toute ma carrière avec pour objectif d’inventer ma propre méthode de développement en décloisonnant le développement et en me rapprochant le plus possible de l’utilisateur jusqu’à développer dans leur entité métier.

Une fois nommé, comme tout le monde, j’ai fait mes classes chez le constructeur : Système d’exploitation (JCL), Assembleur, Fortran, Cobol, LCP… et selon nos préférences de langage, l’Assembleur nous destinait à intégrer l’équipe système, le Fortran, les statistiques et le Cobol, la gestion. J’ai opté pour la gestion.

Le service Documentation jouait un rôle important dans notre auto-formation. Périodiquement, une revue de presse concoctée par notre documentaliste circulait dans les bureaux avec une liste d’émargement et une liste des derniers ouvrages acquis. Un formateur permanent organisait régulièrement des formations animées par un intervenant extérieur. Nous-mêmes étions sollicités pour assurer des formations en vue de faire partager nos acquis.

■ § 1.3. Autoformation

Fin des années 60 – début des années 70, les fichiers étaient des fichiers consécutifs sur bandes magnétiques. Les disques n’existaient pas encore, ni les terminaux, ni à fortiori l’éditeur.

La programmation comportait plusieurs étapes :

• L’analyste : Rédaction de l’analyse de la fonctionnalité à programmer,
• Le programmeur : Conception de l’algorigramme à partir de l’analyse, Écriture du programme au crayon noir HB sur des feuilles de saisie,
• L’atelier de saisie : Saisie du programme sur cartes perforées,
• L’exploitation : Compilation du programme source => programme binaire (cartes perforées),
• Le programmeur : Test du programme compilé.

1969-1970 : J’étais durant cette période, opérateur-pupitreur. Les programmeurs corrigeaient leurs programmes à l’aide de cartes octales de couleur, réalisées avec une perforatrice manuelle, et ajoutées après le programme compilé. Sur le dessus du programme compilé, nous tracions un trait oblique au feutre au cas où… Car les cartes du binaire n’avaient pas de numéros d’ordre comme les cartes du programme source.

1971-1976 : Programmeur à partir de 1971, je n’ai jamais utilisé de cartes octales pour mettre au point mes programmes. Pour autant, les premiers terminaux TTY étaient rares, nous en étions encore au 100% batch et à la carte perforée.
Pour mettre au point nos programmes ou assurer leur maintenance, nous faisions manuellement ce que l’on fait aujourd’hui avec un éditeur. C’est-à-dire avec notre crayon, notre gomme, nos feuilles de saisie et nos cartes perforées. Autant dire que l’on avait intérêt à programmer correctement du premier coup. J’ai continué toute ma carrière à développer correctement du premier coup.

1977-1980 : Affecté à la Maintenance, nous disposions d’une TTY pour tout le service (6 développeurs).
TTY (TeleTYpewriter), sorte de machine à écrire connectée (téléscripteur). En 1980, notre TTY a été remplacée par un terminal écran mais nos programmes "conversationnels" fonctionnaient toujours ligne à ligne.

Autoformation

Par autoformation, j’entends ne pas attendre passivement des recettes à appliquer mais être actif intellectuellement, réfléchir, penser par soi-même, s’interroger, piller, entretenir sa curiosité pour enrichir son savoir-faire et formater le petit disque dur que l’on a entre les deux oreilles.

Les stages chez le constructeur, langage (COBOL), méthodologie (LCP), enseignent la théorie. Assis à son bureau devant son analyse, il faut s’inventer, traduire ce que l’on a appris en codage sur des feuilles de saisie (25 lignes de 80 cases). La difficulté de mettre au point un programme implique de ne pas se rater.

Mon plus gros programme réalisé dans ces conditions, un programme "conversationnel", totalisait 8.000 lignes, soit 320 pages de rédaction au crayon. Heureusement, entre temps, nous étions passés des GE 400 à l’IRIS 80, des bandes aux disques de 600 millions de caractères.

Mon parcours initiatique, mon excellente orthographe et peut-être mes années de dessin industriel, m’ont permis de penser et créer dans l’instant mes tables BDD, mes écrans, mes états, mes documents administratifs. Face à une problématique, tout s’organise instantanément dans mon cerveau. Pas besoin de réunions, de modèles conceptuels, pas de tâtonnements. C'est pratiquement parfait du premier coup.

Si la programmation se limitait à l’usage d’un langage, on ne parlerait pas d’apprentissage de la programmation mais d’apprentissage d’un langage.
 
Programmer ne consiste pas à coder pour coder comme le suggèrent tous les exercices d’algorithmique, c’est-à-dire avec pour seul objectif en tête, un unique problème théorique. Programmer, c’est concevoir le code optimal traduisant une réflexion plurielle gouvernée par un mode opératoire.

Chaque programme est développé selon l’adoption de règles personnelles, d’un mode opératoire qui s’affine, qui s’adapte aux langages et aux diverses évolutions techniques. Ces règles personnelles rendent le développement quasi « industriel ».

Il ne s’agit rien d’autre que de concevoir un AGL minimaliste de développement, le moins contraignant possible, pour optimiser, standardiser la programmation, pour créer une continuité intellectuelle d’un programme à l’autre, pour organiser une synergie des investissements plutôt que de programmer isolément chaque programme.

■ Mode opératoire du « serial développeur »

Intelligible, le programme est impacté par :

• l'AGL
  
  • l’Environnement de Développement Intégré (EDI)
    
  • un AGL minimaliste
  
  
• la simulation comportementale de la problématique,
  
  • [TUTORIEL] Imprimer des numéros de table en piles
    
  • [TUTORIEL] Homogénéiser la répartition d'un tableau
  
  
• la méthodologie de programmation,
  
  • Divagations méthodologiques
    
  • Logique de Construction des Programmes
    
  • La programmation rationnelle
    
  • Méthodologie de programmation LCP
  
  
• l’algorigramme de la problématique,
  
  • [TUTORIEL] Algorithmique - Algorithme - Algorigramme
  
  
• la lisibilité du code,
  
  • les règles de nommage
    
  • les règles de développement
  
  
• les commentaires,
  
  • Manuel utilisateur

Fonctionnel, le programme est impacté par :

• les soft skills,
  
  • Soft skills
  
  
• le shell
  
  • Ex&Co Shells
    
  • OSMOSE Shells
  
  
• la compréhension de la problématique,
  
  • Quelles idées avez-vous de l'utilisateur final lors du développement d'une application
  
  
• l’ergonomie (utilisation) et la convivialité (compréhension) de la fonctionnalité,
  
  • IHM : Différences entre « ergonomie » et « convivialité »
  
  
• l’identité visuelle du logiciel.
  
  • Charte graphique

Aparté Il se trouve qu’entre 1981 et 1984, j’ai suivi une formation permanente pour l’obtention d’un DUT Informatique. Cette formation s'adressait à des professionnels aguerris, autodidactes et sans diplôme. Le DUT ne me servait à rien puisque j’étais dans la fonction publique où une promotion ne dépend pas d’un diplôme mais d’un concours. L’intérêt était de savoir ce qu’il s’y disait, d’officialiser en quelque sorte ce que j’avais découvert par moi-même. Concernant l’apprentissage de la programmation, était-ce parce que nous étions déjà des professionnels, toujours est-il qu’à part un cours sur la méthodologie LCP et une heure sur la conception d’un écran par un professionnel auto entrepreneur qui enseignait à l’IUT pour pouvoir le mettre sur sa carte de visite, je n’ai jamais rien entendu concernant la façon de programmer (simulation, règles de nommage, règles de mise en page, etc.). Ces sujets sont-ils abordés dans le cycle universitaire des étudiants ou appartient-il à chacun d’y réfléchir lui-même ?

À partir d’un écran ou d’un état, on peut estimer le degré de réflexion du développeur et déceler, par exemple, s’il tient compte ou non des difficultés visuelles de beaucoup d’utilisateurs, de leur éventuelle fatigue mentale, ou du fait que la plupart des gens ne lisent pas. La simple conception d’un écran ou d'un état met en évidence l’esprit d’analyse et de synthèse, la créativité, la technicité, la simplicité, la personnalité, l’empathie du programmeur.

L’apprentissage de la programmation ne se termine jamais vraiment, on est toujours en mode recherche. Il suffit parfois de peu de chose pour reconsidérer sa façon de programmer, le design original d’un écran aperçu par hasard, une instruction délaissée qui devient capitale comme le MOVE CORRESPONDING du COBOL ou le PRINT FILE du SGBD INFORMIX.

Deux programmes fondateurs

Les applications batch d’autrefois mettaient en œuvre trois programmes principaux, contrôle, mise à jour et édition.

Mes deux premiers programmes en tant que professionnel, une mise à jour et une édition, ont formaté durablement ma démarche de développement. Mes collègues, "conditionnés" depuis plus longtemps que moi n’ont jamais vraiment réussi à penser par traitements, en termes d'actions. Irrésistiblement, leur réflexion en termes de conditions finissait par s’imposer.

Mise à jour

À la suite de la formation LCP qui terminait mon cycle de formation chez le constructeur, je me suis installé par hasard dans un bureau où 7 collègues développaient l’application de gestion du personnel du Ministère.

Les développements étaient sur le point de se terminer mais il manquait encore le programme le plus important, la mise-à-jour. Deux tentatives de développement n’avaient pas abouti et la troisième venait d’être interrompue. Le chef de projet a alors manifesté son impatience et exhorté l’équipe à prendre ses responsabilités. Ne faisant pas partie de l’équipe et n’étant pas sollicité, sans doute à cause de mon inexpérience supposée en programmation, j’ai quand même relevé le défi en proposant :

- « Si vous vous voulez, je veux bien le faire votre programme ! »

Une analyste (ex-prof de math) qui avait fait le stage LCP avec moi, m’avait vu à l’œuvre au cours de ce stage et s’est immédiatement proposée pour faire l’analyse.

Réponse du chef de projet :

- « Pourquoi pas, on n’a plus rien à perdre. »

Deux mois plus tard, le programme était développé. Ce fut mon premier algorigramme LCP et mon premier programme en tant que professionnel. Les collègues qui ont maintenu mon programme ont respecté ma façon de programmer. Il a géré le personnel pendant 14 ans. Ma façon de programmer a intrigué beaucoup de monde. Notamment notre formateur qui un jour m’a présenté un enseignant, curieux de voir mon programme. Sa réflexion a été :

« Ah bon ! C’est comme ça que les professionnels travaillent ? »

Puis il est reparti avec le listing de mon programme. Deux particularités ont dû l’interpeller, mes noms de données préfixés de l’étiquette logique de leur fichier et la structuration "LCP" de mon programme.

Aujourd’hui, préfixer les noms de données du nom de leur table est une convention, pour ne pas dire une règle SQL. L’étiquette logique du COBOL s’est juste transformée en un pseudo court (2 à 5 caractère) du nom complet mais théorique de la table. Ainsi, les tables "Départements", "Communes", "Établissements", etc. se nomment concrètement "DP", "CM", "ET", etc. à l’instar des étiquettes logiques d’autrefois.

J’avais réalisé ce programme en appliquant les principes LCP que je venais tout juste d’apprendre. Ce fut un effort mental très important car je devais me débarrasser de la démarche par conditions qui m’avait jusque-là été enseignée. Ce fut vraiment deux mois d’effort mental quasi permanent, y compris dans les transports et chez moi. À cet effort mental s’en est ajouté un autre, car mon analyste me donnait son analyse en CORIG. La démarche CORIG est à l’opposé de la démarche LCS (Logique de Construction de Système). L’analyse CORIG découpe la problématique en tâches. Je devais donc traduire le besoin en lisant les tâches horizontalement. La programmation CORIG quant-à elle, est une démarche verticale, linéaire dont l’exécution de chaque fonctionnalité dépend du résultat de conditions.

L’algorigramme LCP d’une mise à jour est une succession de structures alternatives qui s’étirent horizontalement vers la droite.

Mais ce que ma programmation ne montre pas, c’est ma démarche intellectuelle. Ma programmation ne se limite pas à transcrire l’analyse dans un langage. Je m’approprie la problématique, l’efficience des programmes que je développe ne dépend que de moi et de mon implication.

À travers l’analyse, je cherche à comprendre ce qu’attendent le chef de projet, l’analyste et surtout l’utilisateur. J’alimente un dialogue entre les différents intervenants. Cela m’amène à m’interroger, à faire préciser certaines informations par l’utilisateur, à ajouter éventuellement de nouvelles données, de nouvelles fonctionnalités.

Édition

Mon programme de mise à jour terminé, l’équipe a été dissoute pour constituer de nouvelles équipes de développement. Oublié, j’ai dû laisser mon poste de travail et retrouver une place ailleurs. J’ai pu m’installer trois bureaux plus loin où une équipe développait une application pour le compte de l’Office des Vins.

Le chef de projet, jeune Ingénieur des Travaux Ruraux, s'initait à l’informatique et l’un des développeurs faisait son stage en entreprise dans le cadre de son DUT Informatique.

L’ambiance dans ce bureau était plutôt tendue, chacun travaillant en silence, concentré sur son listing. Tout à son travail, le chef de projet laisse échapper :

- « On ne sera jamais dans les temps, on va avoir des pénalités de retard. »

À leur grande surprise, je leur dit :

- « Si vous voulez, je peux vous aider ? »

J’ai d’abord été testé avec un programme d’édition d’erreurs que j’ai écrit en une semaine avec quasiment une seule instruction, un « MOVE CORRESPONDING », le seul que j’ai utilisé dans toute ma carrière de coboliste. Rassurés, ils m’ont confié LE programme d’édition de l’application, un programme qu’ils considéraient comme particulièrement complexe. Deux mois plus tard, le programme imprimait les premières fiches d’encépagement et l’application était opérationnelle dans les temps. Le programme sera vendu quelques années plus tard au CIVC (Comité Interprofessionnel des Vins de Champagne).

La difficulté d’un programme d’édition réside dans la gestion des en-têtes et des sauts de pages que l’on doit intégrer dans la structure LCP.

Un algorigramme d’édition est souvent une succession verticale de structures alternatives. Avec ce programme, ce fut donc mon deuxième algorigramme LCP. Après ça, je n’ai plus eu besoin d’en réaliser, je développais à main levée.

Contrôle

L’algorigramme d’un programme de contrôle s’accorde très bien avec la démarche CORIG en se déployant verticalement en une succession de traitements à faire ou à ne pas faire.

■ § 1.4. Conclusion

Algorithmique

On propose des exercices corrigés d’algorithmique mais enseigne-t-on vraiment l’algorithmique ?

Les exercices corrigés d’algorithmique sont censés être compris par le lecteur mais ils ne s’accompagnent ni d’un raisonnement argumentée, ni même d’un algorigramme. Il appartient au lecteur de s’approprier le raisonnement de l’auteur à la seule lecture du code ou du pseudocode.

L’algorithmique, c’est comprendre le processus logique d’une problématique et identifier l’enchainement des étapes à automatiser. Cela suppose de mener une réflexion sur le sujet mais réfléchir est un cheminement intellectuel personnel et spécifique à chaque problématique. Chaque méthodologie de programmation propose sa recette, son modèle de réflexion.

On peut expliquer pédagogiquement le cheminement de sa propre réflexion vis-à-vis d’une problématique mais cela ne constituera aucunement une référence, une démarche reproductible qui dispense d’une réflexion personnelle influencée ou non par la pratique d’une méthode de programmation.

Programmation

On apprend un langage, un système d’exploitation (Shell), une méthodologie mais enseigne-t-on vraiment la programmation ?

Programmer, c’est structurer logiquement le non-dit d’une problématique. Concrètement, cette structuration logique passe par trois phases :

• Concevoir le Fichier Logique d’Entrée (FLE).
  Autrement dit, identifier et structurer les entités, leurs identifiants et leurs attributs nécessaires à l’obtention d’un résultat.
  
  
• Concevoir le Fichier Logique de Sortie (FLS).
  Autrement dit, identifier les besoins en sortie et les corréler structurellement aux entrées.
  
  
• Concevoir l’algorithme du traitement.
  Autrement dit, structurer logiquement les traitements permettant à partir du FLE d’obtenir le FLS. Selon que le programmeur est étudiant, débutant ou confirmé, la conception de l’algorithme peut nécessiter trois représentations successives : pédagogique, graphique et mentale.

Programmer résulte d’un raisonnement logique et d’une réflexion synthétisant plusieurs savoirs propres à chacun de nous. On peut éventuellement expliquer pédagogiquement le cheminement de sa propre réflexion vis-à-vis d’un développement mais chaque développement est spécifique et chaque développeur possède son propre raisonnement, sa propre expérience.

Un programme est une œuvre de l’esprit, une œuvre originale qui porte l’empreinte, la patte, le style, l’expérience, la conception personnelle de son créateur, le programmeur.

Il suffit, à partir d’un énoncé très simple, de soumettre la création d’un écran à 30 programmeurs chevronnés pour obtenir 30 versions différentes.

Apprentissage

Ma période d’apprentissage s’est étalée de mi-1966, j’avais 18 ans, à mi-1971. Au cours de ces cinq années d’apprentissage de la programmation, j’aurais été successivement « Préparateur de commandes », « Coursier », « Militaire », « Chômeur », à nouveau « Coursier », « Opérateur-Pupitreur » et enfin programmeur.

Évidemment, je n’ai rien conservé de mes premiers cours d’assembleur chez EPSI et je ne me souviens que de la pédagogie des cours du Ministère des Finances pour expliquer la condition. Un dessin en trois parties représentant en haut, un réservoir de billes de couleurs, au milieu un labyrinthe de tubes et en bas des bocaux, chacun censé recevoir les billes d’une même couleur. Après mon stage LCP, j’en ai beaucoup voulu à cette pédagogie qui avait participé au formatage de ma réflexion en termes de conditions.

Échappant à un destin d’ouvrier, j’ai eu la chance grâce à mes prédispositions et à ma détermination de faire partie des pionniers de l’informatique. Depuis la fin des années 60 jusqu’au début des années 90 pour certains, jusqu’à la retraite pour d’autres, mes collègues et moi avons vécu ensemble, passionnément, les mutations technologiques et la diversification de l’informatique. Ces 30 premières années de l’informatique ont correspondu à notre tranche de vie 20-50 ans. Notre lieu de travail, un ancien monastère, a été l’épicentre de notre vie professionnelle et sociale. Après notre apprentissage de la programmation, chacun de nous a tracé sa propre route mais la trentaine de pionniers que nous étions au début continue de se fréquenter cinquante ans plus tard.

L’un de nous qui avait choisi le Fortran a sorti pendant quatre ans presqu’exclusivement des tableaux statistiques avant de passer le concours d’Attaché de l’INSEE. Étudiant pendant deux ans à l’ENSAE, il s’est fait détacher de l’INSEE au SCEES, puis affecter successivement à l’INSEE Paris et Orléans.

Un autre a misé sur le CNAM. Ayant obtenu un DUT d’économie, une maitrise d’organisation et une maitrise d’informatique, il a terminé sa carrière comme Ingénieur Technico-Commercial dans différents services publics : pompiers, police, lycées, services techniques, etc.

Un autre encore a révolutionné la bureaucratie du ministère en s’intéressant très tôt à la bureautique. Ce fut le sujet de mon mémoire à l’IUT Paris-Descartes en 1983-84.

Quant-à moi, j’ai déjà évoqué mon parcours tortueux de fonctionnaire, jalonné par ma quête obsessionnelle d’un contexte favorable à ma recherche des mécanismes d’un développement bottom-up dans l'entité métier de l'utilisateur.

Nous avons pris des directions différentes mais toujours animés de notre esprit pionnier, ce besoin d’avancer dans l’inconnu, de découvrir, d’apprendre, de réfléchir par nous-même, de tracer notre propre route.

Vous pouvez retrouver la suite de mes aventures dans un précédent sondage qui propose un autre éclairage de notre apprentissage de la programmation :

07/11/2016 Sondage : Pourquoi avez-vous choisi de devenir développeur ?

06/02/2017 Message : Inventer ma propre démarche d’informatisation

1. On peut dire que je suis né programmeur
2. La passion pour la résolution de problèmes
3. La passion pour le codage
4. Inventer ma propre démarche d’informatisation

---

■ ■ ■ SOMMAIRE ■ ■ ■

1. L'algorithmique/La Programmation
2. L'algorithme/Le Programme
3. Définition de l’algorithme/Définition du programme
4. Les 3 formes d’un algorithme/Les 3 parties d’un programme

■ Algorithme vs Programme

L’algorithmique ne se réduit pas à l’expertise d’un langage. Un algorithme, c’est la logique d’un programme et non le programme lui-même. Le programme ne fait que traduire l’algorithme. Tous les exercices d’algorithmique proposent des lignes de code en guise de solution. Cela induit la confusion qu’un algorithme est un programme.

L’algorithmique requiert un ensemble d’aptitudes qui s’interconnectent : la réflexion, l’observation, la simulation, l’analyse, l’imagination, le raisonnement, la logique… Il y a autant de différences entre un algorithme et un programme qu’entre un architecte et un maçon.

Ce commentaire met en parallèle ce que représente l’un par rapport à l’autre.

ALGORITHME	PROGRAMME
L’algorithmique est l’étude et la production de règles et de techniques pour concevoir des solutions à des problèmes sous la forme d’un enchainement rigoureux d’opérations à effectuer. Ces solutions exprimées dans un langage descriptif ou représentées graphiquement à l’aide de symboles sont des algorithmes. Apprendre l’algorithmique, c’est apprendre à structurer logiquement sa réflexion pour élaborer la solution à un problème sous forme d’un programme. Si l’on compare un programme à une dissertation, l’algorithmique serait le plan, une fois mis de côté la rédaction et l’orthographe.	La programmation consiste à traduire un travail de réflexion algorithmique en un langage de programmation. Cette traduction constitue le code source des programmes qui composent un logiciel. Le code source, ce sont donc des lignes de code (commandes en anglais) écrites dans un langage de programmation compréhensible par l’ordinateur. On utilise plutôt le terme développement pour définir l'ensemble des activités liées à la création d’un logiciel. Cela inclut la spécification du logiciel, sa conception, puis son implémentation proprement dite au sens de l'écriture des programmes dans un langage de programmation bien défini, les tests, la correction, la maintenance, etc.
L'algorithme L'algorithme décode le problème (son processus itératif) NB : Un processus, c'est une ou plusieurs étapes qui transforment un état initial en un état futur d'achèvement. La première étape pour concevoir la solution à un problème consiste à analyser le problème, c'est-à-dire à en cerner les limites et le mettre en forme dans un langage descriptif ; on parle généralement d'analyse pour décrire le processus par lequel le problème est formalisé. Le langage de description utilisé pour écrire le résultat de l'analyse est appelé algorithme. L'algorithme est le moyen pour le programmeur de représenter son approche du problème. Un algorithme doit donc être : Lisible : l'algorithme doit être compréhensible même par un non-informaticien. Indépendant : l'algorithme doit pouvoir être traduit en n'importe quel langage de programmation, il ne doit donc pas faire appel à des notions techniques relatives à un langage particulier ou bien à un système d'exploitation donné. Précis : ses éléments ne doivent pas porter à confusion. Concis : un algorithme ne doit pas dépasser une page. Si c'est le cas, il faut décomposer le problème en plusieurs sous-problèmes. Structuré : un algorithme doit être composé de différentes parties facilement identifiables.	Le programme Le programme code l'algorithme NB : Programmer, c'est automatiser un processus. L'étape suivante consiste à traduire l'algorithme dans un langage de programmation spécifique, il s'agit de la phase de programmation. Le langage de programmation est l'intermédiaire entre l'humain et la machine, il permet d'écrire dans un langage proche de la machine mais intelligible par l'humain les opérations que l'ordinateur doit effectuer. Ainsi, étant donné que le langage de programmation est destiné à l'ordinateur, il doit donc respecter une syntaxe stricte mais pas seulement. Un programme doit être : Explicite : Son objet décrit sommairement ses fonctionnalités. Lisible : Rendre le programme aussi lisible qu'un document écrit afin d'éviter le recours à tout dossier d’analyse ou de programmation, à tout algorigramme. Le programme ne doit pas n’être que du codage. Il doit respecter une mise en page, des règles de codage. Il doit avoir un fil conducteur, un style, une démarche, une réflexion, une grammaire, une personnalité. Structuré : Algorithme et programme doivent avoir la même structure, laquelle dépend de la méthode de programmation pratiquée (CORIG, LCP, modèle entités-relations).
Définition de l’algorithme Un algorithme est une suite exhaustive de tâches (conditions-actions) ordonnée logiquement et permettant de résoudre une problématique. On peut donc dire qu’un algorithme transforme un problème en solution. Indépendant de tout langage de programmation, l’algorithme permet de visualiser, de modéliser, de structurer le programme à développer. Un algorithme est l’ébauche d’un programme exprimée en pseudocode et/ou décrit visuellement par un algorigramme.	Définition du programme Un programme est un ensemble d’instructions, codées dans un langage doté de règles syntaxiques à respecter. Destinées à être traitées par un ordinateur, ces lignes de code (code source) seront interprétées par un compilateur puis exécutées via des lignes de commande shell (interface entre l’utilisateur et le système d’exploitation). Un programme peut être vu comme un algorithme exprimé dans un langage de programmation spécifique. Les termes algorithme et programme désignent alors la même réalité.
Les 3 formes d’un algorithme Pseudo langage ou pseudocode : L’algorithme a alors une structure linéaire comme un programme. Il décrit une démarche conceptuelle en termes simples dans un langage naturel (pseudo langage) ou dans un langage de programmation purement conventionnel (pseudocode), exempt de toute contrainte syntaxique spécifique d’un langage. Purement conventionnel, un pseudocode est susceptible de varier légèrement d’un livre (ou d’un enseignant) à un autre. Algorigramme : L’algorigramme (organigramme, logigramme, ordinogramme, diagramme) est la représentation graphique composée de symboles méthodologiques d’une démarche conceptuelle logique. L’algorigramme se construit en se conformant à une méthodologie de programmation. Ce n’est pas le cas en ce qui concerne le tutoriel Introduction aux algorigrammes dont la symbolique se réfère à la norme ISO 5807 du 15 février 1985. Ces symboles graphiques datent en réalité des années 1960 et sont associés à la méthode dite sauvage de l’époque. Autrement dit, en ignorant les méthodologies de programmation, l’algorithmique stagne depuis plus d’un demi-siècle. Exemple d’algorigramme Forme mentale : Les développeurs expérimentés peuvent se passer d’exprimer concrètement l’algorithme sensé précéder la programmation. L’algorithme n’en existe pas moins mentalement.	Les 3 parties d’un programme Les variables Les variables comprennent souvent des paramètres transmis au programme via le shell. Les données Ce sont les attributs des tables de la Bases de Données auxquels peuvent s’ajouter des données issues de requêtes SQL. Les traitements Développés dans un langage spécifique, les traitements sont de deux natures : Transactionnels (écrans) Batch (éditions) Préalablement au traitement batch, les données font l’objet de la création d’une table temporaire dont les attributs sont extraits des tables de la BDD via des requêtes SQL et auxquels peuvent s’adjoindre des données calculées par des fonctions SQL.

---

---

§ 6.1. La logique séquentielle

En théorie des circuits électroniques, la logique séquentielle est un type de logique dont les résultats ne dépendent pas seulement des données actuellement traitées mais aussi des données traitées précédemment. Elle s'oppose à la logique combinatoire, dont les résultats sont fonction et seulement fonction des données actuellement traitées. Logique combinatoire : Un système logique est dit combinatoire si à tout instant, il est possible d’écrire l’équation logique de chaque sortie, en fonction seulement des entrées. Le résultat logique en sortie peut donc être représenté par une table de vérité ou un tableau de Karnaugh. Logique séquentielle : Un système est dit séquentiel si à une même combinaison des variables d’entrée peut correspondre plusieurs combinaisons différentes des variables de sortie. La combinaison des variables de sortie dépend des entrées mais également de l’état antérieur des variables de sortie. La logique séquentielle fait intervenir le temps. Autrement dit dans un système séquentiel, la valeur d'une variable logique à l'instant donné T dépend de celles qu'avaient les variables logiques aux instants précédents (instant T-1). C’est ce que l’on appelle « l’effet MÉMOIRE ». On retrouvera les mêmes états des entrés à plusieurs étapes, alors que les sorties seront différentes. Il est donc impossible de les représenter par un tableau de Karnaugh. Caractéristiques d’un système séquentiel Il n’y a plus, contrairement au cas des systèmes combinatoires, de relation d’équivalence entre l’état des entrées et l’état des sorties : Une même cause (traduite par une combinaison d’entrées) peut produire des effets (traduits par la combinaison des sorties) différents, Indépendamment de l’état des sorties, le temps peut être une cause de modification des sorties, Un effet peut persister même après disparition des causes qui l’ont généré. Décomposition en macros De façon à rendre compréhensible et lisible l’algorigramme de description d’un système, il est judicieux de décomposer le comportement en tâches élémentaires qui seront décrites par un algorigramme simple. L’algorigramme général fera alors appel à ces différents algorigrammes simples, appelés macros. PS : La logique séquentielle est un type de logique en théorie des circuits électroniques, mais le concept ne peut-il pas s’appliquer également au traitement des BDD ? J'ose le parallèle… Tout ce discours n’engage que moi. Mais comment expliquer ma démarche ? De quel algorithme s’agit-il ? Pour répondre à ce questionnement, je me suis inspiré des cours sur la Logique séquentielle trouvés sur internet. Notamment : Logique_sequentielle_cours.pdf FPGA - Logique séquentielle et conception RTL (Register Transfer Level)

---

§ 6.2. Logique combinatoire vs Logique séquentielle

Logique combinatoire : les formules de calcul dans les cellules ne changent pas la valeur des attributs quelque soit l’ordre de tri du tableau.

Logique séquentielle : les formules de calcul dans les cellules changent la valeur des attributs si l’on change l’ordre de tri du tableau. Il convient après des calculs, de coller les valeurs des cellules sans leurs formules.

Options de collage :

• Sélectionner les cellules de la colonne (1 à n)
• Copier la sélection (Ctrl/C)
• Clic droit (ouverture du menu contextuel)
• Coller les valeurs sans leurs formules (123 : valeur (V))

---

§ 6.3. Démarche Top-down vs Démarche Bottom-up

Adapter la problématique de l’utilisateur à sa technicité n’est pas la même chose qu’adapter sa technicité à la problématique de l’utilisateur.

Dans le premier cas, la démarche de développement suggère une approche Top-down avec sa logique combinatoire et dans le second cas, elle suggère une approche Bottom-up avec sa logique séquentielle.

• Soit la technicité pilote une démarche Top-down Développeur ◄- Utilisateur.
  
  Le développeur adapte la problématique de l’utilisateur à sa technicité.
  
  
  Envoyé par seven7

  Généralement ça se passe comme ça : Caricature des balançoires
• Soit la philosophie pilote une démarche Bottom-up Développeur -► Utilisateur.
  
  Le développeur adapte sa technicité à la problématique de l’utilisateur. Il utilise sa technicité (L’Art) et sa philosophie (La Manière) pour comprendre et traduire informatiquement la solution que lui inspire la problématique.

---

§ 7. LIENS

La discussion s’est développée dans deux directions, l’une algorithmique et l’autre philosophique. Chacun de ces deux thèmes fait l’objet d’une synthèse publiée sous forme d’un billet de blog.

La synthèse algorithmique se trouve dans mon blog logique ALGORITHMIQUE.

La synthèse philosophique se trouve dans mon blog logique FORUMS.

Trois sujets abordés dans cette synthèse philosophique font l’objet de trois billets distincts dans mon blog logique DIVERS. L’idée est de développer davantage ces sujets, à l’occasion.

Rappel : un blog logique se concrétise de deux façons :

• par une page personnalisée (5 maximum) définissable dans le tableau de bord du blog (Modifier les pages personnalisées) et accessible dans le bloc d’en-tête du menu latéral du blog principal,
  
  
• par une catégorie utilisateur définissable dans le tableau de bord du blog (Gestion des catégories) et accessible dans le bloc "Catégories" du menu latéral du blog principal.

Blog logique ALGORITHMIQUE

[TUTORIEL] Ordre de passage d'une épreuve de concours équestre

[TUTORIEL] Ordre de passage d'une épreuve de concours équestre.docx

Blog logique FORUMS

[Discussion] Ordre de passage d'une épreuve de concours équestre

Blog logique DIVERS

Penser out of the box

Comprendre la communication comme un partage d’expérience et non comme un échange d’informations

Empathie émotionnelle - Empathie cognitive

---

Fin - Exercice corrigé d’algorithmique (Force 6/7)

Ordre de passage d'une épreuve de concours équestre

Billet COMMENTAIRES

Je n’autorise pas les membres à commenter mes billets individuellement afin de préserver leur lisibilité et de conserver leur caractère de publication. Mes propres commentaires doivent être considérés comme des Notes de bas de page.

Afin toutefois d’établir un dialogue constructif avec les membres, je propose ce billet COMMENTAIRES dédié aux éventuelles observations sur le fond et sur la forme de cette publication. Les commentaires sur ce billet étant modérés, celui-ci sera progressivement actualisé et structuré pour assurer sa qualité.

---

2020-10-25 Commentaires déjà publiés

J’ai supprimé mes premiers commentaires sur mes deux premiers billets et les ai transférés dans ce billet COMMENTAIRES, histoire d’initier le processus.

---

2020-11-05 Sous-ensembles de blog

J’ai concrétisé ce que j’avais imaginé à propos de la Description du blog. Le résultat est très satisfaisant grâce à l’affichage inattendu de l’option graphique :fleche:

Pour concrétiser mon deuxième sous-ensemble dans les Catégories utilisateur comme je l’ai évoqué, il faudra attendre la publication d’un billet pour ce sous-ensemble ; mais je suis en panne d’inspiration et surtout de motivation.