Enseirb-Matmeca Filière Informatique
AtoS Intégration : Immersion dans un projet d’intégration SAP
Auteur : Hugo Dodelin Responsable : Floréal Morandat
Maître de stage : Anne Cousseau
Glossaire Acronyme pour Entreprise Resource Planning , aussi nommé Progiciel de Gestion Intégré en français, ce sont des logiciels qui visent à rassembler l’ensemble des processus informatisés de gestion d’entreprise au sein d’un même logiciel. Il est donc capable à lui seul de fournir les informations nécessaires aux utilisateurs de manière complète et cohérente. ERP :
Certainement l’ERP le plus utilisé par les grandes entreprises, il a été crée en 1972 par l’entrprise SAP basée en Allemagne. SAP signifiait à l’origine SystemAnalyse und Programmentwicklung avant d’être changé en Systems, Applications and Products in data processing plus adapté à l’international. SAP :
Le langage de programmation créé pour développer la plateforme SAP puis utilisé au sein de celle-ci pour développer des programmes spécifiques à une entreprise, ABAP signifiait à l’origine Allgemeiner Berichts-Aufbereitungs-Prozessor avant de devenir Advanced Business Application Programming ABAP :
Le besoin client est découpé en tickets, un ticket représentant en général un programme ou une fonctionnalité désirée par le client. Il existe donc 2 types de ticket : Maintenance : Correction d’un programme qui ne répond pas/plus au besoin. Évolution : Création d’un nouveau programme ou ajout de nouvelles fonctionnalités à un programme existant. Ils correspondent à un nouveau besoin. Ticket : • •
1
Résumé Au cours de ce stage, mon occupation principale a été le développement de programmes spécifiques pour le logiciel SAP. SAP sert à planifier la production d’une entreprise. L’idée de base derrière l’utilisation de ce type de logiciel que l’on appelle ERP, est de fédérer toutes les fonctions de l’entreprise en un seul logiciel et une seule base de données commune plutôt qu’en utiliser une multitude et gérer de nombreux problèmes aux interfaces et autres incohérences dans les données. Utiliser un ERP demande un investissement important de la part de l’entreprise. En effet, chaque entreprise ayant sa propre organisation, il faut adapter le logiciel aux besoins du client, ce qui nécessite de faire appel à des professionels ayant une solide expérience du métier, et les développements sont souvent longs et couteux. Mon travail au cours du stage a donc été de participer à différents projets d’intégration de systèmes SAP et, dans le cadre d’un projet en particulier, d’intégrer activement une équipe de développement et donc, de suivre ses rituels quotidiens et adopter ses méthodes et processus comme exigé d’un employé à part entière, si ce n’est que je ne devais avoir aucun contact avec le client. Dans l’ensemble, il m’a été plus difficile de m’adapter à l’aspect organisationnel du travail qu’à son aspect technique, et ce parce que le travail demandé était, malgré les premières apparences, très proche de la formation fournie par l’ENSEIRB, alors que les exigences en matière de rigueur, qualité du code et des tests étaient plus difficiles à satisfaire que ce à quoi j’étais habitué.
2
Introduction N’ayant pas de projet professionel parfaitement défini pour l’instant, j’ai recherché des stages dans plusieurs domaines d’activité différents. J’ai en particulier postulé pour ce stage, car un de mes amis plus âgé que moi travaille actuellement sur SAP et avait lui-même découvert le métier lors d’un stage chez AtoS qu’il avait décrit comme une bonne expérience, aussi j’ai postulé à ce stage dans le but de découvrir un métier qui pourrait possiblement me convenir. Mon stage s’est donc déroulé dans les locaux d’AtoS à Pessac durant 4 mois. J’y ai participé à plusieurs projets, ce qui m’a permis d’avoir des expériences relativement variées. J’ai été entre autres été intégré à l’équipe du projet ADP (Aéroports de Paris)et suis également intervenu dans une moindre mesure sur le projet Stelia Aerospace et un autre projet que je ne suis pas autorisé à nommer. Le travail réalisé relevait principalement des domaines du développement, du test, de la rédaction de documents et de l’analyse.
3
Table des matières Glossaire
1
Résumé
2
Introduction
3
1 Présentation de l’entreprise
5
1.1 AtoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 La division SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 5
2 Description de la mission
6
3 Solutions utilisées
7
3.1 3.2 3.3 3.4
SAP ECC HP ALM . MDM . . SRM . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4 Travail réalisé
4.1 4.2 4.3 4.4 4.5
Organisation . . . . . . Développement ABAP Documentation . . . . Analyse . . . . . . . . Paramétrage . . . . . .
7 7 8 8 9
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
5 Validation du travail réalisé
9 10 10 11 11 12
5.1 Revues de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12 12
Conclusion
13
Bilan personnel
14
4
1
Présentation de l’entreprise
Ce chapitre présentera l’entreprise AtoS, la division SAP où j’ai travaillé et comment je m’y suis positionné en tant que stagiaire. 1.1
AtoS
AtoS est une grande Entreprise de Services du Numérique implantée dans 72 pays dont l’effectif est d’environ 100.000 employés. L’entreprise possède un chiffre d’affaires d’environ 10G e, toujours en augmentation et a récemment fait l’acquisition de la société Bull ainsi que d’ACS qui appartenait anciennement à Xerox. Elle est donc plutôt sur la pente montante. Le site de Pessac en particulier possède des emplois dans les domaines suivants : Intégration de systèmes Infogérance Services Technologiques Big Data • • • •
1.2
La division SAP
La division où j’ai travaillé avait pour finalité l’intégration de systèmes SAP cohérents et efficaces chez le client (des grandes entreprises en général). Les bureaux étaient de type « open space », les membres d’un même projet étant regroupés par îlots de postes de travail afin de faciliter la communication. En outre, l’ensemble du personnel utilise Microsoft Lync pour échanger au sein de l’entreprise. De plus, AtoS donne la possibilité à ses employés d’effectuer une portion de leurs horaires de travail à leur domicile et non sur le site (Télétravail), par conséquent, j’ai dû travailler avec des gens sans être directement en contact avec eux, ce qui était un peu déroutant au début, mais facilité par les outils utilisés qui permettent en réalité de communiquer de manière parfaitement efficace en partageant son écran et/ou en en donnant le contrôle à son interlocuteur par exemple. Je n’avais jamais réalisé auparavant de réel stage en entreprise et ai donc rencontré quelques problèmes de communication/timidité, particulièrement au début. En effet, il est assez difficile d’être hardi face à l’inconnu. Néanmoins, comme il est très rare d’avoir des visites de clients (la plupart des communications sont à distance), la plupart des employés travaillent simplement en t-shirt et l’ambiance est généralement assez détendue, ce qui aide à se rassurer.
5
2
Description de la mission
Le logiciel SAP est ce que l’on appelle un ERP (Enterprise Resource Planning), l’intérêt de ces logiciels est de permettre à une entreprise (grande souvent) d’utiliser un seul logiciel pour gérer leurs données. Ainsi, on ne travaille que sur une seule version des données et on évite les problèmes d’homogénéité qu’on risque en faisant communiquer plusieurs modèles de données. La gestion d’entreprise ayant beaucoup de composantes génériques, chaque module SAP pré-implémente un certain nombre de fonctionnalités dites « standard », mais fait en sorte que l’utilisateur puisse créer des versions personalisées de tous les composants de SAP (tables de la base de données, types de données, programmes, . . .). Néanmoins aucune entreprise n’est organisée de sorte à pouvoir se limiter au standard de SAP, aussi font-elles appel à des professionels pour développer (en langage ABAP, interne à SAP) des éléments dits « spécifiques »qui répondent de manière appropriée au besoin client. Par exemple, ADP possède un système qui, dans un souci de solidarité, permet à un employé de donner une partie de ses jours de congés à d’autres employés, cette possibilité n’a bien entendu pas été prévue initialement par SAP, aussi AtoS doit créer un programme spécifique qui gère ce don de jours. Les différents profils sont les suivants : Il représente l’équipe auprès du client et le client auprès de l’équipe, il se charge de répartir le travail entre les membres de l’équipe et se porte garant auprès du client de la qualité du produit livré. Chef de projet :
Spécialisés dans quelques modules SAP, ils ont une excellente connaissance du standard SAP. Leur mission est d’assurer la qualité de la documentation réalisée et que le produit livré soit cohérent avec l’ensemble de l’architecture réalisée auparavant. Consultant fonctionnel :
Ils s’occupent de développer les programmes spécifiques qui répondront aux besoins du client à partir de spécifications. Consultant technique :
Ils cumulent les compétences d’un consultant technique et d’un consultant fonctionnel. Ils ont généralement une grande expérience du métier et sont un grand atout pour leur équipe. Consultants technico-fonctionnels
6
3
Solutions utilisées Ce chapitre détaillera les méthodes et outils utilisés pour remplir la mission.
3.1
SAP ECC
SAP ECC (ERP Central Component, le nom actuellement donné au logiciel principal pour le distinguer des logiciels SAP annexes qui sont apparus plus tard) est organisé en modules qui couvrent chacun un secteur précis de la gestion d’entreprise (SD pour les ventes, HR pour les ressources humaines, FI pour la finance, . . .) qui peuvent travailler conjointement comme indépendamment.
Les développeurs et les utilisateurs utilisent le même logiciel, l’environnement de développement étant intégré à celui-ci. De manière générale, on peut dire que SAP est comparable à un framework applicatif dans le sens où il permet d’implémenter un certain nombre de fonctionnalités des logiciels de gestion d’entreprise sans avoir à les réécrire soi-même. Les développeurs créent des « applications »(on parle de transactions) et des « fenêtres »(on parle d’écrans) personnalisées et définissent les actions à effectuer en fonction de leur utilisation. De plus, SAP possède une grande base de données centrale appelée « Dictionnaire de données »auquel on peut ajouter ses propres tables et ses propres types, dans le but d’utiliser des données homogènes pour toutes les applications, encore une fois, dans le but de réaliser toute la gestion informatique de l’entreprise avec un seul logiciel. 3.2
HP ALM
HP Application Lifecycle Management est utilisé pour effectuer un suivi du cycle de vie d’une solution. Il s’agit d’analyser l’expression du besoin client et la spécification fonctionelle et découper le travail à réaliser sous forme d’exigences client qui soient le plus synthétiques possible. On crée ensuite un plan de tests qui doit couvrir celles-ci, c’est-à-dire permettre de vérifier qu’elles sont satisfaites. On peut ensuite simuler un lancement des tests, rapporter leurs résultats et déterminer s’ils sont réussis ou non. On joint généralement des copies d’écran qui sanctionnent le succès ou non des tests et/ou appuient les observations rapportées. L’utilisation de HP ALM n’est bien entendu réelement intéressante que si elle est faite en collaboration avec le client, car l’outil est principalement utilisé dans un souci de transparence envers celui-ci de l’avancement concret des développements.
7
3.3
MDM
MDM signifie Master Data Management . Plus concrétement, c’est une solution qui appartient à SAP mais qui ne fait pas partie de SAP ECC, qui permet de garantir l’utilisation d’une version unique des données dans le cas où des applications (SAP ou non-SAP) différentes sont utilisées et doivent travailler conjointement et, si besoin, d’harmoniser les versions des données des différents environnements. Il permet également de gérer un catalogue centralisé avec du contenu image dans le cas où plusieurs entités partageant un même système SAP pourront acheter le même type d’articles, au même fournisseur ou non. 3.4
SRM
SRM signifie Supplier Relationship Management . Il s’agit également d’une solution SAP « non-ECC ». Contrairement au module MM de SAP ECC qui permet de gérer les achats de l’entreprise seulement en interne, SRM permet d’être directement en contact avec le fournisseur, ce qui permet par exemple de remplir un panier d’achats en choisissant ses articles directement depuis le catalogue du fournisseur, ou encore d’envoyer les commandes d’achat au fournisseur directement une fois qu’elles ont été validées en interne.
8
4
Travail réalisé
J’ai été amené au cours de mon stage à participer à plusieurs projets d’intégration de systèmes SAP. Ce chapitre détaillera le déroulement de mon stage et les travaux qui m’ont été confiés. 4.1
Organisation
Chaque journée commence par une réunion d’un quart d’heure (appelée « Daily Meeting ») environ avec l’appui d’un support visuel (un tableau blanc décoré avec des post-it le plus souvent) où chacun détaille ce qu’il a fait la veille, les problèmes rencontrés et ce qu’il compte faire aujourd’hui, ce qui n’est pas sans rappeler la mélée quotidienne de la méthode Scrum. C’est aussi l’occasion pour le chef de projet de choisir à qui confier les nouvelles tâches à réaliser et, si besoin, déterminer qui a besoin d’assistance dans son travail et dans quel domaine auquel cas, un consultant peut avoir pour tâche annexe de répondre aux questions d’un autre dans un domaine où il est plus expérimenté. Sur les projets où j’ai été impliqué, le travail était effectué selon un modèle proche du Cycle en V . Un projet est découpé en tickets (ou Fiche d’Observation chez ADP) et pour chacun d’entre eux, on suit les phases suivantes avant d’entrer en production : Le client fournit une expression du besoin Un consultant fonctionnel côté AtoS propose des spécifications fonctionnelles au client Un consultant technique rédige ensuite des spécifications techniques Il développe la solution Il réalise des tests unitaires pour vérifier que sa solution satisfait bien la spécification. Un consultant fonctionnel côté client réalise les tests d’intégration/validation pour vérifier que la solution répond bien aux exigences client et est compatible avec le reste du système SAP intégré jusque là. On simule la mise en production de la solution lors de la Vérification d’Aptitude au Bon Fonctionnement (VABF) • •
• • •
•
•
Enfin, au début de chaque tâche assignée, les consultants doivent estimer le temps qu’ils passeront sur chaque tâche, puis donner chaque jour au chef de projet leur Reste à Faire (RAF). Ce genre d’exercice n’a pas d’utilité dans un milieu scolaire, mais dans le cas d’une gestion de projet d’entreprise, les délais estimés sont ceux annoncés au client et que l’on s’engage à respecter. Bien que celà puisse paraître anodin, c’est un exercice qu’il m’a été incroyablement difficile de réaliser. Le problème a été entre autres l’impression que j’avais au début que le RAF devait nécessairement s’estimer de tête, alors que diviser à l’écrit les tâches à faire avant d’estimer le temps à y passer est indispensable si l’on a le souci de fournir un chiffre pertinent, mais l’exercice reste tout de même difficile et sujet à des erreurs. Mes encadrants ont été relativement peu insistants à propos des RAF — sans doute en connaissance de cause — et la plupart 9
de ceux que j’ai fournis se sont avérés complétement faux. Même après quatres mois, je ne pense toujours pas être capable de donner de manière fiable un RAF avec une marge d’erreur faible. 4.2
Développement ABAP
SAP utilise le langage de programmation ABAP qui lui est propre. Il s’agit entre autres du langage qui a été utilisé pour développer la plateforme SAP. Je réalisais principalement le travail d’un consultant technique SAP, aussi, au cours d’un projet, je devais souvent modifier des programmes existants (soit pour corriger un mauvais fonctionnement, soit pour lui ajouter de nouvelles fonctionnalités), je devais alors marquer mes modifications de sorte à identifier par qui et quand elles avaient été effectuées. En pratique, je devais indiquer le numéro du ticket demandant la modification, et, dans un cartouche au début du programme, faire correspondre chaque ticket à la date du jour et au compte utilisé pour faire les modifications (les stagiaires n’ont pas leurs propre compte SAP). Je devais aussi respecter une convention de nommage de variables/fonctions et limiter les accès à la base de données et les utilisations de boucles dans un souci de performance. Dans certains cas, je devais créer totalement le programme qui répondait au besoin client, je devais alors au préalable écrire la structure du programme que je comptais créer et les algorithmes utilisés sur un document texte et les présenter au chef de projet jusqu’à ce qu’il les valide avant de commencer à les écrire réelement. Cette étape était réelement importante car les programmes écrits étant assez volumineux, une faille de conception pouvait impliquer la réécriture d’une quantité importante de code et donc, dans les pires des cas, perdre le travail de plusieurs jours. Je n’avais pas été formé au préalable à SAP et au langage ABAP, de plus, la formation ABAP donnée aux stagiaires avait eu lieu deux mois avant mon arrivée, aussi mes encadrants m’ont-ils laissé quelques semaines pour m’auto-former en me fournissant des supports de formation. Même si ma formation scolaire n’était pas liée à SAP, j’ai eu l’impression qu’elle m’a néanmoins aidée à aborder avec plus d’aisance l’apprentissage du langage ABAP — qui est en soi moins compliqué qu’un langage bas niveau comme le C — et la logique autour de la manipulation des bases de données, les requêtes utilisées étant très proches des requêtes SQL apprises à l’ENSEIRB. Dans l’ensemble, cet aspect de mon stage est celui qui a présenté pour moi le moins de difficultés. Il était en revanche plus ardu parfois de comprendre l’apect fonctionel du comportement attendu de mes programmes, les notions impliquées étant relatives à la gestion d’entreprise ou à la structure des modules SAP en eux-même, des choses nouvelles pour moi et dans lesquelles on ne peut finalement acquérir de l’aisance seulement par l’expérience. Une certaine compréhension de celles-ci est néanmoins très importante, car elle permet de prendre le recul nécessaire par rapport aux exigences pour être force de proposition lorsque le besoin client est flou voire paradoxal — cas de figure peu courant mais pas si rare. En ce sens, l’investissement demandé est différent de ce qui est exigé dans le cadre scolaire où les sujets sont nécessairement sans failles et déjà largement éprouvés, mais cette différence n’est pas désagréable. 4.3
Documentation
Avant de commencer à développer un programme, un consultant technique doit rédiger une Spécificaton Technique Détaillée (STD) qui vise à présenter les objets et les algorithmes utilisés par le programme et dans quel but ceux-ci sont utilisés. Ce document s’adresse principalement à la personne qui aura potentiellement plus tard la 10
tâche de faire évoluer ou de corriger le programme. Ce document est bien sûr mis à jour en même temps que le programme qu’il concerne. Je n’ai pas eu de problèmes notables pour en rédiger, étant donné qu’il s’agissait d’y inclure les réponses aux questions que je m’étais déjà nécessairement posées quant à la manière dont je pouvais répondre au besoin d’un point de vue technique et ressemblaient plus à un compte-rendu de développement qu’à une spécification. 4.4
Analyse
Une partie de mon travail a également été, pour des tickets donnés, à partir de l’expression du besoin client et/ou des spécifications fonctionelles, de créer des arborescences d’exigences dans HP ALM dans le but de les utiliser par la suite pour créer le plan de tests unitaires pour ces tickets. Ce n’est pas en réalité un exercice très difficile, mais pour quelqu’un qui n’avait jamais vu de spécifications ni travaillé sur SAP comme c’étais mon cas en début de stage, le travail à réaliser semblait un peu cryptique au départ. 4.5
Paramétrage
C’est ainsi que l’on appelle les actions du standard SAP qui permettent d’adapter le système au besoin de la société du client en particulier. Même si ces actions relèvent plus de l’utilisation de SAP que du développement, elles doivent être réalisées par des consultants SAP uniquement, et ce pour des raisons de connaissances. Ce ne sont pas des actions très complexes, mais leur mauvaise utilisation peut facilement créer des problèmes. Je n’ai pas eu beaucoup de paramétrages à réaliser, et lorsque c’était le cas, je suivait des instructions très précises et n’avait donc pas besoin de réfléchir à mes actions. Dans le cadre de mon travail de consultant technique, les paramétrages étaient donc plutôt anecdotiques.
11
5
Validation du travail réalisé
Dans le milieu scolaire, les projets s’arrêtent à la date de rendu et plus aucun retour n’est à attendre de ceux-ci après cette échéance. Seule la note attribuée fait guise de « validation »du travail réalisé. Dans le milieu de l’entreprise en revanche, il est primordial de livrer au client un produit fini conforme au besoin exprimé, d’où l’importance de la qualité du produit livré. La validation ou non du travail réalisé s’y fait donc très différement. 5.1
Revues de code
Dans le milieu scolaire, le but d’un projet est d’arriver à atteindre un but fixé par l’encadrant, c’est également le cas dans le milieu professionel — si ce n’est que les objectifs sont fixés par le client — néanmoins, la finalité d’un projet scolaire est de permettre à l’élève d’acquérir de l’expérience dans certains domaines alors que dans un projet professionel, la finalité est le service rendu au client. À l’école, la maintenabilité ou l’évolutivité du code n’est donc qu’un souci d’ordre théorique sur lequel on ne met que peu d’emphase. Dans l’entreprise, c’est un souci d’ordre pratique et donc un impératif. Une fois mes développements terminés, je devais d’abord réaliser une première revue à l’aide de l’outil « Code Inspector »intégré à SAP et adapté par les consultants SAP du client à ses besoins qui m’indiquait automatiquement des « erreurs »et des « avertissements »quant à la qualité de mon code. Je devais alors soit modifier le code pour corriger les points soulevés, soit justifier auprès du chef de projet et du client qu’il était impossible d’obtenir le bon résultat de manière plus performante. Le chef de projet faisait ensuite une revue manuelle de mon code pour évaluer selon des critères objectifs si le code était, en plus d’être fonctionnel, performant, maintenable et évolutif, et je devais modifier le code en cas de manquement. Il m’a été personellement très difficile de m’adapter à ce professionalisme dont j’avais pourtant compris les enjeux immédiatement, et j’ai donc passé beaucoup de temps à modifier mes programmes pour qu’ils atteignent la qualité professionelle requise par le client. 5.2
Tests
J’ai également participé à la conception des tests unitaires pour les développements que j’ai réalisés. De la même manière, lors des projets scolaires, nous étions encouragés à réaliser des tests simplement pour nous aider à envisager à quels problèmes nos développements allaient devoir répondre. En entreprise, les fiches de tests font partie de la documentation du programme, et ne sont donc pas simplement l’affaire du développeur. J’ai été d’ailleurs fortement encouragé à adopter une méthode proche du développement piloté par les tests , c’est-à-dire écrire mon plan de tests avant de commencer à développer mes évolutions, faire en sorte que mes tests passent, et ajouter des nouveaux tests s’il existe encore des exigences client non couvertes par le plan de tests. Une fois le développement et les tests unitaires terminés, le programme est transporté sur un autre environnement SAP pour les tests d’intégration (réalisés par le client). En cas d’échec, je reçevais un retour qui m’informait des causes de cet échec, et je devais donc corriger mon programme de sorte à corriger les problèmes soulevés, ce qui impliquait de créer des nouveaux tests unitaires pour refléter la modification apportée.
12
Conclusion Ce stage m’a permis d’être formé à utiliser le langage ABAP de manière professionelle ainsi que d’être initié à quelques autres technologies liées à SAP. Il a également été ma première expérience du monde professionel en tant que ressource réele de l’entreprise dans le cadre d’une activité directement liée à ma formation. Si on se limite au point de vue d’un utilisateur « lambda »de SAP, il est difficile de comprendre ce que SAP accomplit réelement, mais du point de vue des développeurs, on a affaire à des projets complexes et très longs où il faut faire preuve d’ingéniosité pour parvenir à implémenter une solution qui soit à la fois efficace et ergonomique. Les développeurs SAP font un travail qui est au final très similaire à celui de n’importe quel autre développeur sur un langage plus récent.
13
Bilan personnel Le plus difficile au cours de ce stage a été pour moi la transition entre le milieu scolaire et le milieu professionel. L’aspect communicationnel du travail y est infiniment plus important, en effet, le seul type de travail acceptable est celui qui a été approuvé par le client, et parvenir à ce genre de résultat implique une communication solide entre les membres d’une équipe ainsi qu’avec le client, point dans lequel j’ai toujours le sentiment d’être assez faible. Une autre qualité importante à acquérir est la rigueur exigée par le travail, les bonnes pratiques à adopter systématiquement dans son travail et les méthodes à adopter pour garantir l’emploi de celles-ci. Je ne pense pas que mes quatres mois de stage aient été suffisants malgré tout pour acquérir totalement la maturité nécessaire à la tâche. Les premières semaines, j’ai eu l’impression que le travail qui m’était demandé était presque totalement décorrélé de ma formation, ce qui n’a pas manqué de me déstabiliser un peu, mais avec plus de recul, il m’est apparu que j’avais pu m’adapter avec tout de même peu de difficultés aux aspects techniques du travail. Il me semble donc qu’au final peut-être ma formation couvre-t-elle suffisament de domaines de compétence généraux pour qu’aucun sujet du domaine de l’informatique — aussi nouveau soit-il — ne me paraisse vraiment étranger. Il a été en tout cas beaucoup plus motivant pour moi de réaliser un stage où j’ai été confronté à mes points faibles, ce qui n’était pas le cas lors de mes stages précédents — qui ne m’ont pas paru très formateurs en comparaison. De plus, d’un point de vue technique, je me suis senti réellement monter en compétence dans le domaine de SAP et je serais tout à fait disposé à renouveler une expérience de ce type dans le futur. En particulier, je suis renforcé dans cette idée par mon impression qu’il existe des types d’activités suffisament variées dans le métier pour offrir à un consultant une carrière tout à fait édifiante.
14
