Analyste programmeur
La dynamique du développement informatique, une équation à 3 inconnues
Les 3 inconnues fondamentales de la programmation
Cela va te prendre combien de temps ?
Le compromis temps qualité
Peut-on choisir entre l’analyse et la programmation ?
Dans le fond qu’est ce que l’analyse ?
Dans le fond qu’est-ce que la programmation ?
De l’importance de la communication chez l’analyste programmeur
L’échec est toujours possible
Y-a-t-il une méthode pour prévenir l’échec ?
Dans le fond qu’est-ce que la communication chez l’analyste programmeur ?
Dans les grandes organisations, une répartition des rôles
Les systèmes d’informations partagés entre leur héritage et leur futur
Chacun a son avis sur le système d’information
La nécessaire organisation d’un département études pour traiter les demandes
Les évolutions du poste d’analyste programmeur
Analyste programmeur senior
Le chef de projet
L’architecte applicatif
Chef de projet chef d’équipe de développement
Analyste programmeur
C’est le type d’informaticien le plus répandu, on l’appelle également «développeur», la dénomination d’analyste-programmeur est plus explicite sur la nature des tâches réalisées.
La dynamique du développement informatique, une équation à 3 inconnues
On se souvient que les informaticiens ont été appelés les bricoleurs (une des traductions mot hacker)…
Pour rendre la dynamique de réalisation d’un développement informatique plus explicite, on fait ci-dessous un parallèle entre la réalisation d’un bricoleur et celle d’un analyste programmeur.
| Bricoleur | Analyste programmeur |
| Madame Lucas veut accrocher son téléviseur sur le mur de son salon.
Elle achète un support mural et organise un rendez-vous auprès de Laurent, un voisin bricoleur qui est capable de gérer ce type de travaux contre une rétribution raisonnable. Le samedi matin venu, Laurent arrive avec ses trousses à outils, il réalise un premier diagnostic de la faisabilité de l’opération. |
Madame Lucas, la directrice d’une PME constate que ses commerciaux passent une bonne dizaine de minutes par jour à changer la configuration de leur sélecteur de prix dans le logiciel de gestion commerciale.
Elle demande donc à son développeur Laurent de faire en sorte que l’écran de recherche de prix conserve en permanence la dizaine de critères sélectionnés, sans se réinitialiser à chaque connexion. |
| Le mur est constitué de dalles fixées à 6 cm du mur par le moyen d’un maillage métallique.
Les dalles ont une surface de 70 par 25, alors que la télévision à une surface de 60 par 90. Laurent signale à Madame Lucas que l’accrochage ne sera pas simple. Si l’on veut utiliser le support mural il faudra enlever des dalles, découper dans le maillage supportant des dalles, renforcer la structure autour de la partie enlevée pour ne pas compromettre la tenue de la structure et retailler six dalles. |
Laurent analyse le problème.
Il se trouve que tous les commerciaux se connectent avec le même compte, Si chaque utilisateur se connectait avec son propre compte, directement dans la base de données les préférences des utilisateurs seront conservées. La création de compte n’étant pas compliquée, Laurent propose cette modification d’organisation à Madame Lucas. |
| Etant locataire madame Lucas ne peut pas se permettre les travaux qui rendraient difficile le la remise en état de son appartement à la fin de son bail.
Laurent propose alors 2 alternatives : Première alternative : acheter un support sur pied en remplacement du support mural et placer l’écran sur ce support. Deuxième alternative : suspendre l’écran avec des câbles métalliques fixés depuis le faux plafond. Il faudra pour cela découper deux planches au format des dalles du faux plafond; et y fixer les câbles. |
Cette perspective n’arrange pas madame Lucas, elle ne veut pas avoir à gérer la contrainte d’administrer des comptes utilisateurs.
Laurent propose donc deux alternatives : Première alternative : Modifier l’écran de sélection pour que l’utilisateur puisse ouvrir une sélection de jeux de préférence. Deuxième alternative : utiliser des cookies pour enregistrer localement sur les postes les préférences utilisateur. Laurent a une réserve par rapport à l’utilisation des « cookies », technique qu’il n’a jamais utilisé jusqu’à maintenant. |
| C’est cette deuxième alternative qui est adoptée par Madame Lucas.
Madame Lucas s’occupe de renvoyer le support mural contre un avoir. Laurent approvisionne les câbles et la visserie nécessaire au nouveau mode d’accrochage. L’opération qui aurait dû durer une heure si la configuration avait été favorable a duré environ cinq heures. |
La première alternative est jugée trop complexe ; Mme Lucas demande à Laurent de creuser les « cookies ».
Laurent explore la gestion des cookies pour l’usage de son programme. Après quelques recherches sur Internet Laurent trouve une librairie qui lui facilite le travail, js-cookie. Le développement qui avait été initialement prévu pour une demi-journée a fini par se faire en 2 jours. |
On peut voir que le bricoleur comme l’analyste programmeur sont tributaires d’un
environnement, une solution n’est pas bonne en soi, elle devient bonne quand elle s’inscrit dans un contexte (la configuration du salon pour le bricoleur et le programme de gestion commerciale pour l’analyste programmeur).
Le travail du bricoleur et celui de l’analyste programmeur sont proches car ils demandent une grande capacité d’adaptation. L’un et l’autre font face à des contraintes incontournables, la bonne solution est en quelque sorte négociée en considérant les contraintes d’environnement et la demande du client.
Leur travail est délicat car il présente beaucoup d’incertitudes, le résultat doit satisfaire la double exigence de répondre au besoin (première inconnue), d’intégrer le livrable dans son environnement (deuxième inconnue), et d’être réalisé dans un temps raisonnable (la troisième inconnue).
Le travail de l’analyste programmeur est se situe ici entre ces 3 pôles
Les 3 inconnues fondamentales de la programmation
|
1) Le besoin n’est pas toujours bien défini, il peut varier dans le temps ou bien s’oublier. il peut être irréaliste, c’est la première inconnue pour l’analyste programmeur.
2) L’environnement n’est pas forcément simple à appréhender, l’analyste programmeur est souvent dans la situation d’un peintre qui doit refaire une surface derrière un papier peint, tant que le papier peint n’a pas été enlevé, il ne peut qu’émettre des hypothèses. 3)Le produit, le programme en l’occurrence, a sa propre part de mystère, l’analyste programmeur ne refait jamais le même programme, il ne sait pas toujours jusqu’ou un développement peut l’emmener. |
|
La phase d’analyse est représentée ici en bleu, l’analyste programmeur fait ici un certain nombre d’aller-retour entre l’expression de besoin et l’analyse de l’environnement, il défriche le problème.
La phase de programmation est représentée en rouge, elle démarre après l’analyse, quand les choses lui paraissent suffisamment claires pour aller de l’avant l’analyste programmeur lance la réalisation.
|
Cela va te prendre combien de temps ?
C’est la question de que l’on pose souvent à l’analyste programmeur, le demandeur a besoin de savoir combien sa demande va lui couter, en temps et en argent.
Le produit, le programme, est une inconnue qui n’est vraiment levée qu’au bout du processus de développement.
L’analyste programmeur a du mal à répondre à cette question, et pour cause il ne saura le temps que cela prend que lorsqu’il aura terminé. Une bonne partie du temps imparti à son travail est justement un travail d’investigation. Peux t’on demander à un enquêteur judiciaire en combien de temps il pourra trouver un coupable ?
L’expérience de l’analyste programmeur peut l’aider à répondre à cette question ; plus l’analyste programmeur aura eu l’expérience de développement équivalents, plus il pourra donner une estimation du temps de réalisation.
Le compromis temps qualité
Il y a toujours un compromis entre le temps que l’on passe à améliorer la qualité des programmes, et le temps que l’on peut s’allouer pour livrer.
C’est en quelque sorte une quatrième variable : la qualité.
Il faut toujours pouvoir placer se situer pour savoir si sur une demande en particulier on peut s’accorder le luxe de pousser la qualité, en développement informatique augmenter la qualité d’un programme provoque un temps de développement 3 à 4 fois plus long.
La qualité intervient à deux niveaux :
La Performance : elle peut consister soit à résoudre des problématiques complexes, soit à s’assurer que les programmes s’exécutent dans un minimum de temps et avec un minimum de ressources.
L’Utilisabilité : on l’appelle aussi ergonomie ou intuitivité, c’est la science qui consiste à rendre les programmes le plus facilement utilisable par le plus grand nombre.
Ce qui est simple pour l’utilisateur est rarement ce qui est le plus simple pour le programme, pour rendre le programme vraiment facile d’utilisation, on est amené à faire des recherches, à créer des écrans dédiés pour simplifier le travail des utilisateurs, et à revoir sa copie un certain nombre de fois.
| Diagramme de priorité (Temps, Performance et Utilisabilité) | Exemple de diagramme rempli pour 2 programmes
A) programme ou la qualité de l’ergonomie est importante B) programme la priorité est la rapidité de temps de développement est importante |
 |
 |
Peut-on choisir entre l’analyse et la programmation ?
Dans certains environnements de développement de gros systèmes (et jusqu’aux années 1980), les deux fonctions étaient séparées, on ne pouvait être analyste programmeur. On était soit analyste, soit programmeur.
L’analyste donnait des instructions précises au programmeur sur la façon dont il allait écrire les programmes, il définissait les internes des programmes. Ils rédigeaient un « pseudo code » sur papier, décrivait les chemins d’accès aux données, et le programmeur devait alors retranscrire ce pseudo code en programme machine.
C’était une époque où les phases de codage étaient longues, avant l’arrivée des langages de 3ieme génération, la complexité de la phase de programmation justifiait que l’on sépare les deux postes.
Dans les années 1980 les outils des analystes-programmeurs se sont grandement améliorés avec l’apparition des langages de troisième génération (dont le langage C et Cobol, qui sont encore actuellement largement utilisés).
Les langages utilisés actuellement s’appuient sur un générateur de code ou une machine virtuelle (compilateur ou interpréteur), ils permettent à l’analyste programmeur d’écrire un programme en un jour quand il en fallait 3 avec les langages de première génération, les nouveaux langages permettent d’écrire le même programme en un jour.. il est alors devenu contre productif de séparer le travail de l’analyste et celui du programmeur.
[décrire la notion de couche critique]
Dans le fond qu’est ce que l’analyse ?
L’analyse désigne une démarche intellectuelle, une aptitude à décortiquer et à se représenter une problématique. En psychologie et en philosophie on parle aussi d’entendement
L’entendement en psychologie désigne la faculté de percevoir, de comprendre par l’intelligence. L’entendement se différencie de la mémoire, de la perception, de l’imagination, et de toutes les facultés qui ne font pas appel à la raison.
En informatique l’analyse interviens à plusieurs niveaux, nous avons l’analyse stratégique (ou organisationnelle), l’analyse conceptuelle, l’analyse organique (ou analyse logique).
Ce qui est dans le giron immédiat de l’analyste programmeur c’est l’analyse logique, elle répond globalement à la question « comment je vais pouvoir m’organiser pour répondre à cette demande ».
Pour développer son programme l’analyste programmeur va poser les bases de son programme, soit une exploration autour de la solution.
L’analyse va identifier les programmes existants, les structures de données en place, les données en entrée, les données en sortie, les cas particuliers ; soient les tenants et aboutissants du programme.
En face de l’image mentale du problème, l’analyste programmeur construit une image mentale de la solution : il met à plat les conditions, les traitements itératifs, les algorithmes de calcul qui définissent le programme.
A l’issue de cette phase l’analyste programmeur sait ou il va, il a construit une représentation abstraite et dynamique de son programme. La démarche d’une analyse logique est semblable à celle du début d’un travail de dissertation en français ou de philosophie… on analyse le sujet, on fait un remue méninges pour développer le maximum d’idées, on fait le tri, on priorise, on organise et on bâtit le plan.
Pour mieux comprendre et appréhender le processus d’analyse on pourra se référer au début de la journée de Jean Michel (Annexe03-journal-analyste-programmeur),
Dans le fond qu’est-ce que la programmation ?
Programmer, c’est partir du résultat de l’image mentale du programme, image construite pendant la phase d’analyse, et la mettre en musique.
On commence alors par la rédaction du code, le code rédigé est une transcription de l’image mentale de la solution imaginée pendant l’analyse.
Après la rédaction du code, il faut réaliser de nombreux tests unitaires et de très nombreuses rectifications du programme pour qu’il réponde au cahier des charges.
L’analyse et la programmation sont indissociables, la conduite du développement est basée sur l’appropriation du problème par l’analyste-programmeur, c’est le fil rouge qui le conduit dans tout le processus d’analyse et de programmation. Plus l’analyste programmeur comprend la « problématique client », plus la réponse du programme qu’il va réaliser sera pertinente, et moins il y aura d’aller-retour entre les parties prenantes.
[..] Interagir avec les utilisateurs finaux, les clients finaux, développer un échange pour bien comprendre le besoin. Pas juste bien comprendre les besoins en informatique mais le besoin métier.
(inteview de Vinze)
Dans une phase de développement, la rédaction du code à proprement parler ne prends que 5 à 15 pour cent du temps total. L’analyste programmeur conduit son développement en menant beaucoup de cycles essai-erreur-correction. L’ajustement du code et sa correction prends plus de temps que l’écriture du code. On est loin de l’image du mangeur de code, passant son temps devant son écran.
Pour mieux comprendre et appréhender le processus d’analyse au travail de Jean Michel à partir de 11h (Annexe03-journal-analyste-programmeur),
De l’importance de la communication chez l’analyste programmeur
L’échec est toujours possible
Le développement informatique n’est pas une science exacte, on peut avoir de bonnes surprises mais on a souvent des mauvaises surprises… Les temps de développement peuvent exploser par rapport aux prévisions… Il arrive que des programmes soient jetés à la poubelle ; ils fonctionnent « mécaniquement parlant » mais ils ne sont pas utilisés.
Exemple d’un échec retentissant, l’Opérateur National de Paye
L’objectif était la centralisation de tous les systèmes de paye des fonctionnaires en France, initié en 2007 et abandonné en 2014 ; le projet était destiné à économiser environ 200 millions d’euros par an, et il a coûté beaucoup d’argent (on estime à 1,3 milliards d’Euros), avant d’être abandonné.
Ce projet pharaonique était dès le départ trop ambitieux, dans un contexte ou il existe en France un millier de traitements différents pour l’ensemble fonctionnaires, la complexité du projet n’a pas été estimée à sa juste valeur, il est allé de dérapage en dérapage.
Le fiasco a été anticipé par certains, la directrice de l’ONP Sophie Mahieux a quitté le projet en 2012, et assez rapidement des problèmes de communication se sont accumulés :
- Sur un sujet éminemment sensible beaucoup de ministères ont fait de la « rétention d’information », ne pas jouant pas le jeu et retardant la marche du projet ;
- Karine Berger, députée PS des Hautes-Alpes, s’est heurtée à un mur lorsqu’elle s’est penchée sur le sujet. « A plusieurs reprises », il lui a été « impossible d’obtenir des informations sur des points précis, malgré plusieurs relances ».
L’analyste programmeur doit vivre avec cette éventualité d’échec, dans un processus avec tant inconnues, les plantages sont fréquents. En gestion de projet on parle d’analyse de risques; dans certaines industries on peut s’assurer financièrement pour couvrir certains risques… Mais je ne connais pas d’assureur qui vous assurera contre les risques d’échec de la conduite d’un projet informatique.
En programmation, ce sont les obstacles à la communication qui créent les conditions de l’échec, et c’est pourquoi chez l’analyste programmeur les qualités de communication sont importantes, on pourra même dire aussi importante que la compétence informatique. On lève ici un paradoxe et on enfonce l’image de l’informaticien asocial, cette idée est bien mise en avant par Vinze :
Alors, bon, faut voir une chose, c’est que l’informatique ce n’est pas juste, réaliser les programmes, utiliser les machines, il y a tout un aspect un peu social, on va dire, dans l’entreprise,
Y-a-t-il une méthode pour prévenir l’échec ?
Les méthodes de développement classiques (Merise, UML) ne mentionnent ni des causes ni de la possibilité de l’échec. Elles montrent un monde idéal et elles vous bercent dans l’illusion que votre projet va fonctionner si vous appliquez la méthode, ce qui est loin d’être vérifié…
Une méthode de gestion de projet prend en considération une vision vivante et réaliste du développement informatique, c’est la méthode « extreme programming » (https://fr.wikipedia.org/wiki/Extreme_programming) . Cette méthode met en avant une communication intense comme premier moyen pour éviter l’échec des projets; et elle s’appuie aussi sur la responsabilité des acteurs. En suivant cette méthode, l’analyste programmeur doit communiquer dès que possible sur sa capacité à faire ou ne pas faire comme prévu, il doit être transparent.
On étudiera plus en détail la question du succès et de l’insuccès des projets au chapitre 19.
Dans le fond qu’est-ce que la communication chez l’analyste programmeur ?
La communication au démarrage : Développer une écoute rigoureuse pendant les phases d’expressions de besoin a impact important. Si il y a un cahier des charges, il faut qu’il soit lu de façon attentive jusqu’au dernier mot, en ayant l’ambition de le comprendre. Si la communication est orale, l’analyste programmeur doit reformuler les instructions et développer un dialogue pour s’assurer que les instructions soient comprises. Il est très rare que les cahiers des charges soient bien écrits et exhaustifs. Trop souvent l’analyste programmeur s’arrange de certaines imprécisions, et démarre le développement malgré une compréhension partielle du besoin.
L’analyse de programmeurs doit renvoyer ce type de messages :
- Je ne comprends pas ton cahier des charges.
- Est-ce que tu pourrais préciser tel et tel point ?
- Cela va prendre entre 5 et 10 jours de travail, et il va falloir telle et telle modification sur le programme existant, tu penses que cela vaut vraiment le coup ?
La communication en cours de projet, l’analyste programmeur doit une transparence suffisante qui permette de recadrer le projet lors ce que cela a un coût moindre.
Après l’analyse, arrivé à un certain point dans les premiers développements, l’analyste programmeur a une vision plus claire du temps que cela peut prendre, et des limites qu’il pourra rencontrer.
Il doit pouvoir émettre ce type de message :
- J’ai pensé que cette partie serait facile, mais en fait les données que j’ai en entrée ne me permettent pas d’avancer, on doit réaliser des développement complémentaires..
- J’ai peur que l’on ait des problèmes de performance, et que l’on soit obligé de changer notre serveur.
- Pour telle et telle raison le projet prendra plus de temps que prévu.. qu’est ce que l’on fait ?
La communication peut également être positive ; « on va pouvoir livrer à l’heure, voir légèrement en avance ».
La documentation et la communication après projet, c’est la communication à l’intérieur de l’équipe de développement, elle explique les choix que l’on a faits et les méthodes d’implémentation choisies.
Dans les grandes organisations, une répartition des rôles
Nous étions partis au début de ce chapitre sur la description d’un cas simple, avec 2 intervenants, dans une relation entre un analyste programmeur et un donneur d’ordre.
Ce qui change la relation entre l’analyste programmeur et son entourage, c’est l’étendue du système d’information et le nombre de ses interlocuteurs potentiels.
Les systèmes d’informations partagés entre leur héritage et leur futur
Les systèmes informatiques des organisations sont souvent protéiformes, ils ont des redondances, ils ne sont pas toujours cohérents.
Quand une entreprise à un certain âge, et c’est le cas de toutes les entreprises d’une certaine taille, elle font cohabiter dans leur système d’information le passé, le présent, et l’avenir, les technologies changent mais elles s’empilent plus qu’elles ne se remplacent.
Le passé désigne les sous-systèmes que l’on a décidé de ne plus faire évoluer. On s’assure qu’ils fonctionnent à moindre frais. On va changer de temps en temps un paramètre, par exemple un taux de TVA, et on va les migrer sur les nouvelles machines si nécessaire.
Le présent est constitué des sous-systèmes utilisés et maintenus quotidiennement; ils évoluent et ils sont régulièrement améliorés.
L’avenir ce sont les développements basés sur de nouvelles plates-formes ; ils ne sont pas encore exploités mais ils occupent l’équipe de développement.
On peut avoir par exemple dans une grosse PME exerçant dans le domaine de la vente d’articles de bricolage.
Le passé c’est un système de gestion commerciale, connecté avec les systèmes de caisses enregistreuses, il tourne sur un mini-ordinateur HP datant des années 1980. Il fonctionne en mode caractères avec 5 consoles, programmé en FORTH.
Le présent c’est un progiciel client-serveur SAGE pour la comptabilité fournisseur et le grand livre; une gestion des approvisionnements et retours de produits avec une application développée in situ sous Microsoft SQL Server et .net
Le futur c’est le système de gestion commerciale que l’équipe informatique est en train de réécrire sous Microsoft SQL Server et .net.
Entre les différents sous-systèmes constituant le passé, le présent et l’avenir du système d’information on trouve des langages informatiques, des machines, des cultures différentes. Pour un analyste programmeur une complexité impossible à gérer s’il n’est pas entouré de personnes qui n’ont pas la connaissance et/ou l’expérience du système.
Chacun a son avis sur le système d’information
Dans une entreprise de 8 000 utilisateurs, vous avez plusieurs milliers d’avis et encore plus de demandes de changements. On peut être surpris par la pertinence et par l’étendue des remarques formulées par les utilisateurs, le système d’information est un sujet d’intérêt et de discussion, en plus d’être le prolongement d’une réflexion stratégique.
Voici une représentation des demandes de changement et de leur traitement, en rouge est représenté ce qui est extérieur à l’informatique et à ses experts, et en bleu ce qui relève la compétence des informaticiens.
Plus l’organisation est grande, plus la diversité comme l’étendue des demandes de changement rend le travail de traitement de ces demandes important.
Les analystes programmeurs ne peuvent pas réaliser ce travail, ils vont donc communiquer avec des experts fonctionnels et techniques du système d’informations.
La nécessaire organisation d’un département études pour traiter les demandes
On doit préciser le sujet, le besoin, avant d’arriver à l’exécution d’une demande de changement. Ce travail de précision est également sélectif. Comme il en coutera trop (en temps et/ou en argent) de réaliser toutes les demandes; on fait des choix et on définit des priorités à chacun des niveaux.
| Le niveau d’analyse stratégique et organisationnel appréhende l’ensemble des processus de l’entreprise, c’est le directeur informatique |  |
| Le niveau d’analyse fonctionnelle va s’appliquer à un domaine, ce sont les chefs de projets qui l’appréhendent | |
| Les analystes programmeurs vont concentrer leurs efforts sur « une fonction », qui est une partie d’un domaine. |
Le travail de l’analyste programmeur change beaucoup suivant la taille de son organisation, dans une petite entreprise les interlocuteurs sont les dirigeants et les utilisateurs du système d’information. Ici en rouge trois super utilisateurs qui échangent avec un analyste programmeur
Dans une grande organisation les interlocuteurs de l’analyste programmeur sont d’autres spécialistes de l’informatique, les chefs de projet, neuf super utilisateurs échangent avec un chef de projet qui gère la communication avec 3 analystes programmeurs
Nous avons donc des chefs de projets (ou experts fonctionnels) à différents niveaux, ils connaissent la dynamique de chaque sous-système, ils sont capables de préparer les ordres de mission pour les analystes programmeurs.
L’évolution du système d’information d’une organisation s’appuie sur plusieurs niveaux de compréhension et d’expertise, chaque compréhension du système se complète et les équipes s’entraident pour améliorer ensemble le système d’information.
Quand il est suivi au quotidien par un chef de projet, l’analyste programmeur n’aura donc plus à se poser de questions sur ses priorités, il aura un interlocuteur pour répondre de façon précise aux questions sur les tenants et aboutissants de ses réalisations (qui ? que ? quoi ? comment ? pourquoi?).
En plus des chefs de projets, l’analyste programmeur peut s’appuyer sur d’autres experts, des architectes, des experts techniques, des administrateurs bases de donnés, ces derniers pourront l’aider dans la résolution de problèmes plus pointus. Il devra aussi se faire aider par les équipes techniques et fonctionnelles dans la compréhension de sous-systèmes existants.
Les évolutions du poste d’analyste programmeur
Après un certain temps de pratique comme d’analyste programmeur (3 à 20 ans), certains expriment le souhait d’évoluer. On peut passer dans la gestion de la production, les défis techniques que l’on peut y relever sont souvent plus variés que ceux du monde du développement.
Voici le témoignage de véronique, qui est passée d’analyste programmeur vers ingénieur système et réseau au CNRS
Je trouve qu’il est très différent d’être dans les systèmes ; en tant que programmeur, il y avait cet aller-retour avec les chercheurs…En système réseau c’était quand même un travail beaucoup plus indépendant en fait. Parce que dès l’instant où le besoin en outil, en puissance de calcul du chercheur était bien identifié après c’était vraiment beaucoup plus autonome sur la façon de gérer, […] on avait la gestion d’un budget et c’est nous qui décidions comment le gérer de la meilleure façon, bien entendu toujours en relation avec les besoins des chercheurs et puis donc la gestion du budget ça passait par l’achat , la réception des commandes l’installation même physique des machines , leur installations évidement avec les systèmes d’exploitation , la mise en réseaux, tout quoi. Tout de A à Z plus installer les logiciels nécessaires pour les chercheurs qui faisaient des calcul pour des modèles de météorologie ; c’était beaucoup plus large comme spectre d’activité par rapport à la programmation proprement dite.
Quand il reste dans le département études, l’analyste programmeur va évoluer en tant qu’analyste programmeur senior ou bien il exercera une autre fonction, il est capable d’évoluer soit vers une fonction plus technique comme architecte applicatif, ou d’être plus en communication avec les utilisateurs finaux comme chef de projet fonctionnel. Il peut également devenir chef d’équipe de développement et encadrer d’autres analystes programmeurs.
Analyste programmeur senior
Celui qui apprécie beaucoup la programmation peut devenir naturellement analyste programmeur senior, un analyste programmeur expérimenté devient un référent au sein de l’équipe de développement. Il est consulté à chaque fois qu’il y a des problèmes plus pointus, ou quand on rencontre des problèmes d’intégration. Dans le contexte de certaines entreprises, la mise au point d’algorithmes complexes ou l’analyse de certains problèmes demande l’intervention d’analystes programmeurs expérimentés. Dans son livre « la route du futur » Bill Gates écrit qu’une des causes du ratage d’IBM dans le monde de la Micro était l’absence de bons développeurs : « dès qu’un développeur avait du talent il était affecté à des fonctions de gestion ».
Le chef de projet
Un analyste programmeur fera un excellent chef de projet car il connaîtra toute la logique du développement. Il sera en mesure de développer un dialogue constructif avec les utilisateurs finaux aussi bien qu’avec l’équipe de développement.
C’est une évolution naturelle pour un analyste programmeur qui a de bonnes capacités de communication et des aptitudes à la rédaction de dossiers fonctionnels.
L’architecte applicatif
C’est un métier qui me convient bien à ceux qui aiment développer une expertise est une relative autonomie dans le travail, l’architecte applicatif va rester les deux pieds dans la technique, c’est un métier qui induit une communication intense avec la direction générale, les chefs de projet, les analyses programmeurs ; ses missions sont variées :
La publication de normes de qualité de développement et l’application du contrôle qualité par des revues de code.
La veille technologique et de la prospective pour pouvoir accompagner l’organisation dans les choix stratégiques en évolution du système d’information.
La réalisation de prototype pour pouvoir mettre en pratique mettre en pratique de nouveaux choix d’architecture
Chef de projet chef d’équipe de développement
Cela conviendra à quelqu’un qui aime bien l’organisation, qui est ouvert et sait développer la cohésion dans une équipe de travail.
Il a la responsabilité d’embaucher et de faire monter en compétence l’ensemble des membres de son équipe.
Il attribue des travaux à son équipe d’analystes programmeurs, il vérifie la bonne conduite de développement et le respect des standards de qualité.