Programmation ordinateurs

Un ordinateur suivant la définition complétée par Von Neumann, est une machine algorithmique dont l'ensemble des programmes sont enregistrés dans sa mémoire vive ou l'une ou l'autre de ses mémoires périphériques.
Dans sa mémoire, le programme est dans une forme dite "exécutable", c'est à dire une forme binaire interprétable directement par les circuits logiques de la machine.

Par programme d'ordinateur on entendait en 1940, 1950, 1960, la série d'instructions qui définissent la série d'opérations élémentaires que la machine doit effectuer pour exécuter une ou plusieurs tâches données. On utilisait alors des instructions définies en langage binaire, plus tard, on utilisa des langages de base transformés ensuite par un programme "interpréteur".
A chaque instruction élémentaire correspond la commande d'un circuit logique (électro-mécanique ou électronique).

Cette définition est restée valable depuis les machines à cartes perforées et les premiers calculateurs jusqu'à l'apparition, au début des années 1960, des "systèmes opératoires".
La logique de programmation est représentée graphiquement par des organigrammes. Parfois par des diagrammes logiques ou une combinaison des deux.

La photo jointe représente un organigraphe de programmation.("template" en anglais). C'était l'instrument de base du programmeur depuis que la codification symbolique des organigrammes de programmation fut standardisée. Il s'agit ici d'un Minerva des années 1975, mais il en existait déjà dans les années 1950. Avant, je ne sais pas.
On retrouve des symboles correspondant aux opération physiques : tri, interclassement, unités de traitement,...et logiques : le "ou" , les aiguillages conditionels, ....
L'organigraphe comporte aussi une règle métrique et une règle en pouces qui sert à la mesure des états imprimés.
Sur les côtés, on retrouvait dans les modèles des années 1970 des accolades, pour aider aux représentations en programmation dite "structurée".
Son usage se perd, remplacé par des documents numériques.
Plus loin dans la page, une photo de la règle du programmeur, qui comporte des aides à la définition des dimensions d'édition et des sauts de lignes.

Les systèmes opératoires sont des séries de programmes chargés de gérer et coordonner les fonctionnalité de base de la machine. Ils sont réalisés pour une fois pour toute pour une série de machine. Actuellement , par exemple, UNIX, LINUX, WINDOWS sont des systèmes opératoires. Les systèmes opératoires sont, en quelque sorte, l'interface entre les logiciels d'application et le matériel.

La programmation des applications prend maintenant un sens plus vaste : il s'agit de l'ensemble des instructions à définir pour résoudre un problème donné, sans s'occuper des spécificités propres à une machine donnée, mais en tenant compte du ou des systèmes opératoires prévus et des langages disponibles.
On programma ainsi via des "langages" élaborés tels anciennement FORTRAN, COBOL, BASIC, RPG et maintenant C et C++, HTML, JAVA, ...(la liste est longue, tant des anciens langages que des modernes).
Pour ce qui concerne les ordinateurs qui furent vendus par Bull, GE, Honeywell, CII, consulter les tableaux des langages de programmation présentés dans ce site.

Un programme est une unité logique d'exécution. Une application, un logiciel, un progiciel sont constitués d'une multitude de programmes, appelés en mémoire au fur et à mesure des besoins.

Toutes ces notions sont explicitées dans de multiples ouvrages, plus ou moins approfondis.
Le lecteur belge intéressé par ces questions trouvera entre autre en librairie un excellent ouvrage destiné aux étudiants en première année universitaire en Informatique :
« Les fondements de l'informatique - Du bit à l'Internet », par H.Bersini, M-P. Spinette et R. Spinette. La dernière édition de cet ouvrage a paru fin 2008 chez Vuibert (France)

On fait encore la distinction entre programmation de gestion et programmation scientifique.
Un programme de gestion a essentiellement pour but de rapprocher des données réparties dans différents fichiers ou dans une ou plusieurs bases de données, aux fins de constituer un autre fichier ou de les présenter à l'utilisateur.
Un programme scientifique réalise essentiellement des opérations mathématiques sur un ensemble de données.
Les premiers calculateurs électroniques programmables permirent ce genre de programmation. Ce fut le cas du Gamma 3 ET chez Bull.
Ensuite, je cite un exemple donné par Bernard Nivelet :
"L'essentiel des calculs impliquent des produits de matrices et de vecteurs.
La première approche sérieuse pour résoudre efficacement ce genre de problèmes fut celle de Cray dans les années 60: construire un matériel implémentant directement les opérations vectorielles sur 48 bits: +, - et x.
Elle trouva ses limites avec la taille des opérateurs à manipulés: matrices nxp et vecteurs n, avec n de l'ordre de 10**9 et p inférieur à 10....
La seconde approche apparut dans la seconde partie des années 80 avec les multiprocesseurs: au lieu de faire un matériel dédié spécialement aux opérations vectorielles, on délègue à un nombre immense de processeurs 64 bits standards les opérations vectorielles.Celles-ci impliquent en boucle: load A, load B, C=A*B, store C. Le point important est que l'opération "*" prenait en flottant beaucoup de fois plus de temps que les opérations load et store...
Depuis les années 2010, les chips micro-processeur incluent des opérations vectorielles, ce qui donne à chaque nœud d'un multiprocesseur la performance d'un Cray..."

La "microprogrammation" des puces électroniques, des microcircuits, des micro-processeurs, du déroulement des tâches partagées entre micro-processeurs diffère fort de la programmation des applications. Elle se fait dans des langages adaptés, genre C++, et doit tenir compte de l'architecture des systèmes. Nous n'en tenons pas compte dans ce qui suit.

Si , sur Internet, la littérature abonde concernant les langages de programmation, l 'accent a été moins mis sur les difficultés qui furent et sont encore rencontrées par les rédacteurs de programmes, les programmeurs. J'en reprend une liste, non exhaustive :

Il n'est pas facile de bien saisir toute la portée et les nuances définies par l'analyse fonctionnelle et détaillée du problème. L'analyse est un travail spécifique qui ressort généralement de la responsabilité de l'analyste ou du chef de projet. Une analyse incomplète ou mal transmise ne peut conduire qu'à un programme inadapté aux besoins des utilisateurs. Divers outils existent pour éviter de tomber dans ce piège.

Programmer de manière efficace suppose de concevoir une bonne structure générale de ce programme. Chaque fonction particulière : affichage de résultat, fonction de calcul, fonction de recherche, etc fait l'objet de sous-programmes ou tâches appelées par le programme principal. On dira alors du programme qu'il est "structuré". Une bonne structuration est essentielle pour assurer une bonne fiabilité du programme.

S'il est devenu relativement simple d'écrire un programme, il est difficile de concevoir des "jeux d'essais" qui reproduisent les conditions d'emploi du programme.
Ainsi la phase de test est-elle critique et nécessite la collaboration active de futurs utilisateurs. Le programmeur imagine mal la manière dont un non informaticien va réagir face à ce que lui a prévu.

Un programme quel qu'il soit doit respecter des normes de réalisation, en vue d'en faciliter les corrections et les adaptations futures.
Un programme vite fait mais mal conçu finira par coûter très cher en maintenance.

Les applications qui tournent actuellement sur les grands serveurs informatiques impliquent des millions d'utilisateurs. Le moindre défaut dans un programme entraîne des coûts énormes. Cela se vit encore régulièrement quand un opérateur (télécoms, télévision, banque, ..;) procède à l'introduction d'une nouvelle version de son logiciel.

Le dialogue entre analyste et programmeur doit aboutir à un dossier d'utilisation (aide, mode d'emploi) précis et clair. S'il peut exister des lacunes dans les explications d'un programme de correction de photos ou même d'un tableur, il ne peut exister aucune ambiguïté dans les explications concernant un programme comptable ou de gestion des approvisionnements, par exemple. Bien entendu, ces explications qui se retrouvaient à l'époque dans un dossier papier et sont maintenant rendues disponibles via le poste de travail de l'utilisateur.

Plus des programmes sont destinés à un grand nombre d'utilisateurs, plus il faudra les rendre faciles à utiliser, faciles à comprendre et clairement documentés.
Ils doivent se présenter dans la langue des utilisateurs. En Belgique, au Québec, en Suisse on ne pourra présenter une application que si elle est au moins bilingue.

Le travail produit par un programmeur ou une équipe de programmation est souvent sous-traité à une firme extérieure à l'entreprise propriétaire du produit.
Cela entraîne une difficulté supplémentaire : la validation de programmes fournis.

Il est souvent demandé au programmeur de corriger ou modifier des programmes dont il n'est pas l'auteur. Cela demande une grande souplesse d'esprit.

Si les langages de programmation sont relativement standards, les environnement dans lesquels les programmes sont censés tourner ne le sont pas : Unix, Linux, Windows, Systèmes propriétaires, O.S. pour téléphones intelligents.... Le programmeur devra en tenir compte quand il fait appel à des routines ou des interfaces avec les systèmes opératoires.

Pour certains programmes, tels les éditeurs, les anti-virus, par exemple, il faut une bonne connaissance des interfaces avec les systèmes opératoires dans lesquels ils sont censés fonctionner. Pénétrer la connaissance de ces interfaces n'est généralement pas chose aisée. Rappelons que la condamnation de Microsoft par la Commission Européenne concernait précisément la non publication par ce dernier des interfaces opératoires de son système Windows.

Comme dans bien des domaines, parmi les pièges qui attendent le programmeur, un des pires est la ou les modifications des spécifications en cours de travail.
Dans le pire des cas, une modification peut entraîner un bouleversement complet de la structure du programme.
En tout état de cause, le programmeur doit tenir son propre journal des modifications, car retracer celles-ci après quelque temps devient vite impossible. Il ne doit jamais compter sur l'analyste ou le chef de projet pour le faire à sa place, car eux ne mesurent pas toujours le poids des modifications demandées.

La Méthode WARNIER

- Qui était Jean-Dominique Warnier ?

C'était un ingénieur à la Compagnie des Machines Bull devenue Bull-GE en 1965. Son passé était assez inattendu : il fut prêtre dans une communauté liée aux "prêtres ouvriers"et était de plus licencié en théologie ! Dans les années 1960 il enseignait la logique Binaire et l'Algèbre de Boole aux jeunes recrues de la Compagnie, à l'école "Bull" rue des Vinaigriers. Certains anciens se souviennent encore de lui comme d'un collègue très agréable, très à l'écoute et très patient. D'autres aspects du personnage et son œuvre (la méthode LCP) sont évoqués dans une page de Pierre Fischof : http://www.adeli.org/document/759-l84p26pdf en référence :

- Comme son nom l'indique, la méthode LCP (Lois de Construction de Programmes) est prévue pour la programmation et non l'analyse. Sinon rétrospectivement, celle d'un programme en particulier. En anglais : Logical Construction Programing.
- Cette méthode a été imaginée par Jean-Dominique Warnier in ingénieur français qui travaillait chez Bull dans les années 1960-1970. La méthode a été enseignée en France, Il ne semble pas qu'elle ait été mise au catalogue du Centre de Formation de Bull en France.
- Par contre en ce qui concerne Le groupe Bull en Belgique, elle a été enseignée pendant près de 12 ans.
- Il semble d'autre part que LCP n'ait jamais eu de véritable succès en entreprise. Elle y était prônée pour la formation des programmeurs, voire surtout une recherche d'harmonisation des dossiers de programmes. Cependant elle était ensuite relativement vite abandonnée par les programmeurs eux-mêmes pour une certaine lourdeur allongeant leur temps de travail. Mais la plupart d'entre eux en ont conservé certaines idées, notamment les principes de présentation en FLS et FLE, soit l'étude séparée en fichiers logiques des Sorties et des Entrées.
- Il y avait effectivement cette petite guerre idéologique entre partisans et adversaires. Le plus acharné des partisans à Bull en Belgique était certainement Claude Frenay. Quant aux adversaires, ils reprochaient non seulement la multiplication des schémas préparatoires avant de réaliser l'organigramme en lui-même, mais surtout la présence de nombreux paragraphes vides introduits par la méthode.
- La non-formation de tous les programmeurs Bull et cette dissension interne ont été à la base de la non-utilisation en clientèle par le personnel de Bull. Ceci explique certainement aussi le peu de succès à terme de cette méthode en entreprise.

- Les travaux de Jean-Dominique Warnier sont certainement à la base d'évolutions importantes dans les méthodes de programmation, dont la programmation dite "structurée", où l'on définit un structure logique de cœur du programme, chaque élément du coeur

-Plus généralement il apparait que l'œuvre de J.D. Warnier ai eu un impact au niveau mondial, lequel a marqué et marque encore les sciences informatiques, le Génie logiciel et les approches Objet.
La méthode Warnier a permis en effet de diffuser la formation à l'informatique et aux systèmes d'information :
- dans les instituts universitaires de technologie français : les IUT, Instituts Universitaires de Technologie, les MIAGE, formations en Méthodes Informatiques Appliquées à la Gestion, et au CNAM (Conservatoire National des Arts et Métiers),
- en Afrique,
- en Amérique latine,
- en Amérique du Nord
- et dans la plupart des pays d'Europe de l'Est ...
contribuant souvent ainsi au rayonnement français et francophone dans le monde, ainsi que l'appropriation aisée de l'informatique par bien des compagnies, des pays et des peuples.

Mme De Rocquigny (cfr références) signalait en particulier que la méthode a donc servi à former une génération d'informaticiens à cette époque.
Cela a créé des tensions entre "anciens" formés sur le tas et "jeunes diplômés". Les acteurs de l'époque opposent volontiers le « paquet de nouilles » du Cobol et le travail méthodique et documenté favorisé par la méthode Warnier.
Dans les grandes entreprises du CIGREF, la méthode n'a pas été généralisée.
Selon un ancien de la STERIA - SSCI - elle était utilisée (formation déployée en interne ; mise en œuvre dans les développements) afin de construire un corpus de connaissance mobilisable."

Voir notamment "Les Procédures de Traitement et leurs Données", Warnier, Jean-Dominique, Les Éditions d'organisation, Paris, 1973 (ou 1975 éme éd.) préfacé par l’Inspecteur général de l’instruction publique, Jean Boulanger.
Ses autres ouvrages sont mentionnés dans Wikipedia, page en référence ci-dessous.

Pour ce qui concerne Bull, La Logique Informatique a été très vraisemblablement, une des armes majeures de guerre pour le progrès commercial et pour la diffusion de ses matériels et de ses services, ceci permettant ainsi souvent de contrecarrer le poids d'IBM dans le monde et des autres constructeurs. En effet, les filiales des grands constructeurs US ne pouvaient prendre d'initiatives qui s'écartaient de la ligne définie à la maison mère.

Enfin, à noter qu'en 1978, une association s'est créée pour promouvoir l'utilisation des méthodes préconisées par Jean-Dominique Warnier, sous l'acronyme ADELI (Association pour le DEveloppement de la Logique Informatique). Adeli (association), toujours active en 2014, traite désormais des différents aspects de la maîtrise des systèmes d'information.

J'ai mené cette recherche sur J.D. Warnier en mi-2014, un peu tard donc pour la récolte d'informations.
Des propos ont été recueillis chez Daniel Lhonneux, très longtemps formateur chez Bull en Belgique. Merci aussi, pour leur contribution, à Pierre Fischof consultant, et Pierre Coulon, ancien de Bull et du SCAT France, tous deux membres de ADELI. Sur le site suivant se trouve une intéressante contribution de Pierre Fischof : http://www.adeli.org/document/759-l84p26pdf
voir aussi : http://fr.wikipedia.org/wiki/Jean-Dominique_Warnier
merci aussi pour leur contribution à Marie-Aline de Rocquigny, doctorante en sciences de gestion et l'aide que m'a fournie Isabelle Astic du CNAM.
Je remercie aussi mes amis à FEB qui m'ont fait part de leurs souvenirs.

AUTRES METHODES

Il y en eut bien d'autres, par la suite.

- Parallèlement chez Bull en Belgique, c'était la méthode anglaise BISAD (Business Information Analysis and Design) qui avait été retenue pour l'analyse. Cette méthode a été au catalogue de l'école aussi pendant une bonne dizaine d'années. Elle était présentée en 2 modules : BISAD A / analyse fonctionnelle et B / analyse organique. La formation avait été initiée par Joseph Mariens, puis reprise ensuite pas Yan Embrechts en NL, ainsi que Roger Peeters et moi-même en FR. J'en ai donc donné cours de nombreuses fois. Principalement le module BISAD A qui avait le plus de succès.
- Ce même module BISAD A fût même dispensé de façon "obligatoire" à presque toute la hiérarchie, ainsi qu'aux commerciaux, chefs de projet et analystes. Il fût même question d'une application en interne, mais vu l'ampleur de la tâche, cette idée fut vite abandonnée. Par ailleurs, cette méthode commençant par une étude de l'existant, certaines rumeurs de l'époque ont fait dire que c'était la crainte de la découverte de cadavres dans les placards qui fut à l'origine de cet abandon !

- Quant à Merise, il s'agit uniquement d'une méthode d'analyse d'origine française du milieu des années 80. C'est Daniel Lhonneux qui l'a introduite à l'école de formation Bull en Belgique et qui l'a dispensée principalement dans le cadre des formations Forem / Bruxelles Formation pendant près de 15 ans. A partir de 2003, il l'a progressivement complétée puis remplacée par le langage d'analyse UML. Avec l'arrivée de l'objet, je présume que depuis d'autres méthodes ont vu le jour et qu'elles sont enseignées tant par Bull Paris que par divers centres de formation. En tout cas en Belgique, ni par Bull de par la scission avec Steria, ni par Steria elle-même puisque après mon départ en juillet 2007 et la perte du contrat Bruxelles Formation, l'école a été supprimée en 2009.

propos recueillis chez Daniel Lhonneux

retour haut de page

retour au menu histoire

4 Outils en cours d'étude :

1) Les outils actuels permettent de bien structurer un programme. Mais des laboratoires de génie logiciel se penchent sur des outils qui permettront de vérifier la logique mathématique de la construction du programme en repérant les boucles d'erreur et les en vérifiant la logique mathématique du programme.
La puissance de calcul jointe à une logique formelle permettra de parcourir les très grands nombres de cas offerts par les suites de "if" conditionnels imbriqués
2) Il sera aussi possible d'injecter plus de rigueur mathématique dans la conception des spécifications des programmes, soit la phase d'analyse. Pour cela, la rédaction des spécification se fera à travers des outils spécialisés.
Je signale à ce propos que l'on parle de "Template Programing" à propos de génération de langages tels C++ à partir d'organigrammes. Consulter à ce propos une littérature abondante sur internet.

5 Les Algorithmes :

Dans le cadre de la programmation, pourquoi parler des algorithmes ?
Parce qu'ils ont été dès le naissance des calculateurs les outils de base pour la résolution de problèmes mathématiques. Comme un algorithme est une suite finie d'opérations (d'instructions) répétitives qui tendent à approcher au maximum la valeur recherchée, le calculateur programmable se prête idéalement à sa résolution.
L'exemple de base est le calcul des nombres "Pi" et "e" avec un haut degré de précision.
La recherche de nouveaux algorithmes est devenue indispensable dans de nombreuses applications, telles la simulation, la cryptographie, l'optimisation des ressources, la météorologie, la biologie, la physique des particules élémentaires, le formatage et le compactage des données. Les programmeurs ne peuvent plus se contenter d'avoir l'algorithme qui résout le problème; ils doivent aussi rechercher celui qui demandera le moins de temps de traitement; en effet, même les supercalculateurs actuels sont utilisés pour résoudre des problèmes d'une telle complexité que le temps de résolution pose problème !
J'ajouterais encore l'utilisation d'algorithmes dans des problèmes de mathématique dite "molle", tels qu'il s'en pose en sociologie comportementale par ex.

Dans de nombreux domaines industriels et scientifiques, des logiciels développés il y a des années, ne sont plus adaptés aux architectures dites ultra -parallèles (équipées de milliers de processeurs) des systèmes de calcul intensif d’aujourd’hui. D’après les analystes de l’industrie, seulement 1 % des logiciels étaient en 2012 capables d’exploiter à la fois 10 000 processeurs ou plus. Or les supercalculateurs « exaflopiques » de la prochaine génération compteront plus de cent millions de processeurs. Les concepteurs sont donc confrontés au défi de l’adaptation de leurs logiciels s’ils veulent pouvoir bénéficier de la puissance des infrastructures ultra-parallèles, telles que par exemple, les nouveaux processeurs Intel® Xeon® et les coprocesseurs Intel® Xeon Phi™. Quand ces nouveaux supercalculateurs seront disponibles, seuls les centres de recherche et les industries qui auront parallélisé leurs applications pourront en bénéficier. Une course à l’échelle mondiale est d’ores-et-déjà engagée.
A noter que la Compagnie Bull a créé en 2013, dans ce but, un centre d'excellence destiné aux concepteurs de logiciels