(partie 2) Intégration de Maven dans un projet Java J2EE Hibernate/Spring/Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même !

Intégration de Maven dans un projet Java J2EE Hibernate, Spring, Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même ! (partie 2)

Voici la suite de l'article concernant l'utilisation de Maven avec WTP d'Eclipse.

Le but étant de trouver une solution pour utiliser à la fois Maven et ainsi bénéficier de l'avantage de la gestion de la configuration des dépendances tout en restant WTP "compliant" et ainsi être capable de debugger le serveur dans l'environnement Eclipse.

En fait c'est assez simple, vous prenez votre projet "assembly" maven, celui qui vous permet via maven de générer votre archive web, votre war par exemple et vous exécutez la commande suivante dans son répertoire :

mvn -Dwtpversion=1.0 eclipse:eclipse

Bien entendu vous remplacez "1.0" par R7, 1.5 ou 2.0 en fonction de votre version WTP.

Après ça, un répertoire .settings va être créé à la racine du projet avec un fichier ".component" dans notre cas (version 1.0). Dans ce fichier on va retrouver toutes les dépendances du projet que ce soit les librairies ou les projets dont il dépend. Toutes les dépendances apparaissent sous forme de jars situés dans le dépôt maven.

Problème: en mettant les projets dépendants via leur archive jar sous maven, il n'est pas possible de les modifier en debug sous eclipse. Il faut supprimer les références vers les projets dépendants dans le fichier ".component" pour ne laisser que les librairies utilisées. Ensuite il faut faire un clic droit sur le projet et sélectionner "properties" puis dans la fenêtre qui apparaît il faut cliquer sur "modules dependencies". La prochaine fenêtre permet de sélectionner les projets dépendants, il faut alors cocher tous les projets que vous avez supprimé du fichier .component à l'étape précédente et terminer en validant en cliquant sur OK.

Après quoi il faut vérifier que le fichier .component contient bien les nouvelles dépendances vers les projets fraîchement supprimés puis ajoutés, mais cette fois avec des dépendances de type module ! (et non jar)

Après quoi, il faut ajouter un serveur à WTP si ce n'est pas déjà fait puis ajouter le projet ainsi modifié au serveur WTP... puis le lancer, mettre des points d'arrêts et s'y rendre, modifier le code source "en live", sauvegarder la classe modifiée et prendre soin de builder via eclipse (Ctrl + B ou build auto) et là: contempler le debugger d'Eclipse continuer de debugger normalement.

En fait il n'y a rien de magique dans tout ça, c'est simplement un projet assembly Maven auquel on ajoute la fonctionnalité WTP permettant de debugger... Cette solution à un inconvénient MAJEUR !!! La maintenabilité !!! A chaque dépendance maven ajoutée qu'elle soit de type librairie ou projet... il faudra l'ajouter manuellement (via clic droit properties modules dependencies...)

Je compte me pencher sur ce point ASAP... des pistes ? utiliser WTP 2, tester le nouveau plugin eclipse pour maven, utiliser un script de synchronisation, réécrire WTP... etc...

Fight For Kisses (www.ffk-wilkinson.com)

Quand les calinoutchs viennent à manquer, tous les moyens sont bons !

Désolé mais en voyant ce trailer j'ai eu envie de le partager avec le plus grand nombre...

(partie 1) Intégration de Maven dans un projet Java J2EE Hibernate, Spring, Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même !

Intégration de Maven dans un projet Java J2EE Hibernate, Spring, Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même ! (partie 1)

Il existe des projets qui ne ressemblent pas aux "Hello World" que l'on trouve habituellement sur chaque site de framework digne de ce nom ! En effet, dans certains cas (qui a dit tous les cas ?) les projets sont complexes et leurs ramifications de dépendance font penser à une grande forêt de projet...

Dressons le tableau:
-un serveur web avec Spring, Hibernate, Birt et JMS (entre autre) découpé en couches suivant 2 axes. D'un côté un découpage fonction du type de manipulation des données traitées: DAOs, services métier et services applicatifs et de l'autre un découpage suivant les briques métiers ou les catégories de services (ex: brique "commune" ou "de base", brique achat, brique financière...).
-un client type Eclipse RCP avec des dépendances vers certains projets communs avec le serveur.

Maintenant ajoutons maven pour gérer les dépendances des différents projets serveurs et la c'est le drame ! En effet, les projets communs qui sont à la fois en dépendance maven et en dépendance plugin eclipse posent problème. En effet si un projet A à une dépendance via maven vers un projet B dans le pom.xml ainsi qu'une dépendance vers le plugin B via le MANIFEST.MF alors Eclipse mettra le projet en erreur avec une erreur du type : "Build path contains duplicate entry: 'pluginB' for pluginA"

Aucun problème pour la partie serveur via maven; les scripts maven type clean, package, install etc fonctionneront parfaitement... c'est dans Eclipse que ca se corse. Mais à quoi bon écrire un article s'il n'y a pas de solution ? Aucun et c'est bien pour ça que j'écris ces lignes !

Pour résoudre cette erreur, il faudra utiliser une fonctionnalité quelque peu cachée du plugin maven pour Eclipse:
-Un clic droit sur l'élément "Maven Dependencies" du projet qui a à la fois une dépendance maven et plugin pour laisser apparaitre le menu contextuel.
-Puis cliquez sur "Properties" ce qui permet d'afficher une fenêtre de configuration.
-Décochez la case à cocher "Resolve dependencies from workspace project".
-Validez cette fenêtre en cliquant sur "OK".

On en parle ici: http://docs.codehaus.org/display/M2ECLIPSE/Dependency+Management

Image:

A noter: Eclipse 3.2, plugin maven pour eclipse en 0.0.11 (le 0.0.9 et le 0.0.12 posent problème actuellement dans notre environnement) et maven 2.

Maintenant on se trouve dans un environnement Eclipse qui compile et surtout qui permet de lancer le client en debug ainsi que le serveur via WTP tout en utilisant la gestion des dépendances maven. Enfin l'utilisation du Web Tool Platform d'Eclipse avec Maven mérite un second article car ce n'est pas une mince affaire de les méler tout en permettant au developpeur de debugger le serveur "à chaud" sans avoir à re-builder la totalité de l'application serveur via des scripts maven... en ayant pris soin d'avoir arrêté le serveur et en le démarrant après tout ça.

>> suite >>

La gestion des sauts de page dans un tableau BIRT (pageBreakInside)

Juste un petit message pour noter un point "négatif" dans le framework BIRT, ou plutôt dans une certaine version de BIRT à savoir la 2.1.x !!! (version archaïque diront certains)

En effet, ceux qui se sont déjà confrontés aux problèmes de gestion des sauts de page dans BIRT savent qu'il y a de quoi s'arracher les cheveux !

Mettez nous en situation, vous avez 2 tableaux imbriqués, appelons les T1 et T2 et vous souhaitez que le tableau (T2) qui est contenu dans le tableau principal(T1) s'affiche si possible sur une nouvelle page dans le cas ou il ne peut s'afficher dans la page courante. Attention, vous ne voulez pas que T2 soit systématiquement sur une nouvelle page, mais bien uniquement lorsqu'il ne peut s'afficher sur la page courante. Plutôt simple à priori mais c'est sans compter sur le fait qu'on ne peut gérer les sauts de page que suivant le début et/ou la fin d'un tableau et non en spécifiant le comportement des sauts de page au sein du tableau.

Exemple des données à afficher :

----------------------------
- HEADER T1
----------------------------
- T2: INFO 1
- T2: nom 1
- T2: prénom 1
----------------------------
- T2: INFO 2
- T2: nom 2
- T2: prénom 2
----------------------------
- T2: INFO 3
- T2: nom 3
- T2: prénom 3
----------------------------

Ce que je ne veux pas voir s'afficher : (Ce que génère BIRT 2.1.x)

########## PAGE 1 ##########
----------------------------
- HEADER T1
----------------------------
- T2: INFO 1
- T2: nom 1
- T2: prénom 1
----------------------------
- T2: INFO 2
- T2: nom 2


########## PAGE 2 ##########

- T2: prénom 2
----------------------------
- T2: INFO 3
- T2: nom 3
- prénom 3
----------------------------

Et ce que je souhaite afficher : (Ce que génère BIRT 2.2.x bien configuré)

########## PAGE 1 ##########
----------------------------
- HEADER T1
----------------------------
- T2: INFO 1
- T2: nom 1
- T2: prénom 1
----------------------------

########## PAGE 2 ##########
----------------------------
- T2: INFO 2
- T2: nom 2
- T2: prénom 2
----------------------------
- T2: INFO 3
- T2: nom 3
- T2: prénom 3
----------------------------

Une propriété "pageBreakInside" est sensée résoudre tous nos problèmes, pour plus d'info:
https://bugs.eclipse.org/bugs/attachment.cgi?id=36165
et
http://www.eclipse.org/birt/phoenix/ref/rom/elements/Style.html#Property-pageBreakInside)

Elle va de paire avec les propriétés pageBreakBefore et pageBreakAfter qui elles fonctionnent parfaitement. Le pageBreakInside n'est pas disponibles dans le BIRT Designer 2.1.x et si on ajoute la propriété directement dans le xml elle n'est pas interprétée.

Après avoir étudié de nombreuses pistes diverses et variées... aucunes solution n'a été trouvé enfin si une seule la montée de version de BIRT de 2.1.x vers 2.2.x ! Et donc si vous êtes en Eclipse 3.2 vous serez forcez de passer en Eclipse 3.3 ! Et si vous étiez en Java 1.4, vous serez forcez de passer en Java 5 ! Aie dirons certains, tant mieux dirons d'autres et tant pis pour les derniers.

Java Scripted Datasets avec BIRT: une solution souple et pratique !

BIRT est un projet open-source de la communauté Eclipse.org permettant de réaliser des états (reports) à partir d'un fichier de mise en forme (rptdesign xml), de données diverses (base de données) et d'un moteur de génération des éditions (BIRT engine) le tout dans un monde J2EE.

La plupart du temps, BIRT est présenté comme une solution orientée BI (Business Intelligence)... du décisionnel. Et pourtant, c'est aussi une solution très adaptée pour réaliser des documents pour des applications métiers qui necessitent la réalisation de documents à partir de grappes d'objet métier java et non à partir de bases de données directement.

Je m'explique... dans les exemples BIRT on voit toujours des data sources pour se connecter directement à une base de données or ce n'est pas forcément pratique quand doit réaliser un document qui correspond à un écran pour lequel il existe déjà un service métier permettant de récupérer les données à afficher dans le document.

Pour ce faire, il existe les scripted data sources et les scripted data sets. Ils permettent d'utiliser des objets java pour les afficher dans le document. Par défaut, le data set est codé en javascript au sein de l'éditeur BIRT dans Eclipse. Le code javascript est stocké dans le document BIRT (rptdesign ou rptlibrary). Cela peut poser plusieurs problèmes lors de la réalisation du document.

Premièrement, le javascript est simple certe mais l'éditeur BIRT actuel ne permet pas d'apporter beaucoup d'aide au developpeur (autocompletion, verificateur de syntaxe...).

Deuxièmement, il n'est pas possible de mettre des points d'arrêt pour débugger le document lors de la génération avec le moteur BIRT.

Troisièmement, le code du data set est stocket dans le document BIRT de description de l'édition avec tous les désagréments que cela comporte.

Mais heureusement il existe une ultime solution pour pallier à ces trois problèmes les java scripted data sets ! Ils permettent tout simplement de remplacer les javascripted data sets par une classe java.

La classe java doit implémenter ScriptedDataSetEventAdapter avec les méthodes :

public boolean fetch(IDataSetInstance set, IUpdatableDataSetRow row) { ... }
public void beforeOpen(IDataSetInstance dataSet, IReportContext reportContext) { ... }
public boolean describe(IDataSetInstance arg0, IScriptedDataSetMetaData arg1) { ... }

Exemple:

import org.eclipse.birt.report.engine.api.script.eventadapter.ScriptedDataSetEventAdapter;
import org.eclipse.birt.report.engine.api.script.instance.IDataSetInstance;
import org.eclipse.birt.report.engine.api.script.IUpdatableDataSetRow;
import org.eclipse.birt.report.engine.api.script.IScriptedDataSetMetaData;


public class MyScriptedDataSetEventAdapter extends ScriptedDataSetEventAdapter {

private static final String COLUMN_FOO = "Foo";
private static final String COLUMN_BAR = "Bar";

private int index = 0;
private int size;

private MyObject test;

public boolean fetch(IDataSetInstance set, IUpdatableDataSetRow row) {
if( index >= size){
return false;
}
try{
row.setColumnValue(COLUMN_FOO, test.getListToFetch().get(index).getFoo());
row.setColumnValue(COLUMN_BAR, test.getListToFetch().get(index).getBar());
}catch (Exception e){
//myLogger.log(e) you know wtf to do here ;-)
}
index += 1;
return true;
}

public void beforeOpen(IDataSetInstance dataSet, IReportContext reportContext) {
test = (MyObject) reportContext.getGlobalVariable("myObjectName");
size= test.getListToFetch().size();
}

public boolean describe(IDataSetInstance arg0, IScriptedDataSetMetaData arg1) {
arg1.addColumn(COLUMN_FOO, String.class);
arg1.addColumn(COLUMN_BAR, Double.class);
return true;
}

}

Pour débugger rien de plus simple, mettre un point d'arrêt et lancer l'application en debug...
Pour s'assurer de la syntaxe du code... Eclipse est la !
Pour aider a la récupération des données issues de la grappe métier passée en paramètre à BIRT... encore une fois Eclipse est la !

PS: Par contre pour les projets utilisants BIRT coté client RCP... il peut y avoir des problèmes de partage de classpath... apparement les dataset scipted java ne sont pas trouvé... donc pour le moment méthode a utiliser uniquement coté serveur... a moins que...

Problème de suppression d'objets dans les collections avec Hibernate !

Hibernate est un framework de gestion de la persistance renommé et très connu qui permet bien des choses et avec lequel on peut s'arracher bien des cheveux !

Hibernate à la "facheuse" tendance à utiliser des types collection qui lui sont specifique pour gérer tout ce qui concerne les list, set... Les attributs de type list et set sont remplacés par des objets de type PersistentList et PersistentSet. Cela permet par exemple à hibernate de charger dynamiquement la collection lors de l'appelle à une méthode comme size() add() ou remove() dans le cas par exemple d'une collection mappée avec le lazy loading. Pour résumer, tant qu'on n'a pas besoin du contenu de la liste, elle est remplacé par un proxy qui est pret à al charger à la première demande.

Quand on utilise Hibernate dans le cadre d'une application ayant une architecture client-serveur, les classes d'hibernate ne sont accéssibles que coté serveur, coté base de données. Or dans une architecture client-serveur on fait transiter des objets métiers java de part et d'autre via le réseau (en HTTP par exemple avec Spring remoting) mais sous une condition : Que tous les objets envoyés soit accessibles dans les dépendances des 2 projets.

Or comme je l'ai expliqué juste avant, Hibernate remplace les listes par des objets qui lui sont propres et qui ne sont accéssibles qu'au projet serveur via la librairie hibernate (hibernate3.jar par exemple dans répertoire lib du serveur). Donc si on envoie au client une grappe métier contenant des listes après extraction de la base via hibernate, cela va poser problème et on va voir fleurir dans la console des erreurs du type "Exception : Ahhhhhh je ne connais pas la classe PersistentSet"

Il se peut qu'on ne soit pas impacté par ce problème car il est coutume d'utiliser des DTOs et des transformateurs pour faire transiter les objets sur le réseau et par conséquent les types spécifiques d'hibernate sont transformés automatiquement (par les transformateurs). Dans le cas ou nous n'avons pas de couche de DTOs, on peut utiliser des mappeurs qui remplacent les PersistentList et PersistentSet en ArrayList et HashpSet par exemple.

Bref, une fois les objets récupérés transformés (sans PersistentXXX) sur le client, on joue avec, ou les modifie et on peut être amené à supprimer des éléments d'une liste. Et c'est la que l'affaire se corse car il se peut, sans qu'on sache réellement pourquoi, que Hibernate ne puisse pas détecter la suppression d'un élément donné lors de la sauvegarde.

Effectivement, puisqu'on a remplacer les gestionnaire de liste à la sauce hibernate quand on renvoie la grappe coté serveur... il ne se rend pas compte qu'il y a eu suppression même avec les options type delete-orphan all-delete-orphan dans le mapping... La seule solution, l'ultime chance restante consiste à mapper la liste d'une manière bien différente.

Ce problème commun est connu sur le site hibernate.org :

------------------------------
I removed an object from a collection mapped with cascade="all" but the object was not deleted!

cascade="all" cascades the delete() operation from parent to child. If this is a one-to-many association, try using cascade="all,delete-orphan".

Another solution is to model your child objects as composite elements (a kind of value type) rather than entities. Value types are always persisted or removed along with their parent entity. So you would use a mapping for the element class instead of a mapping..
------------------------------

Voici le mapping de la liste contenu dans mon objet Truc :

<set name="maListe" table="element" lazy="true" >
<key column="elt_trc_id" not-null="true" />
<composite-element class="org.truc.Element">
<parent name="truc"/>

<property name="identifiant" type="java.lang.Integer">
<column name="elt_id" />
</property>

<property name="commentaire" type="java.lang.String">
<column name="elt_commentaire" length="254" />
</property>

<property name="date" type="timestamp">
<column name="elt_date" />
</property>

</composite-element>
</set>

au lieu de par exemple:

<list name="maListe" lazy="true" cascade="persist, save-update, evict, merge, all-delete-orphan">
<key column="elt_trc_id" not-null="true" />
<index column="elt_numero" />
<one-to-many class="Element" />
</list>

Bon les désavantages sont flagrants, on est obligé de mapper la liste dans le fichier de mapping de l'objet conteneur et dans le cas ou les objets de la liste sont utilisés dans plusieurs objets... on duplique on duplique... pas très pro comme on dit alors mieux vaut éviter.

Mais bon ca fonctionne et les objets sont biens mis à jours et surtout supprimés quand on sauvegarde l'objet conteneur...

Birt Eclipse, ça promet !

J'étudie la mise en place de Birt sur un projet Client Riche basé sur Eclipse RCP et j'avoue être quelque peu bluffé par certaines fonctionnalités bien sympathiques de ce framework de reporting.

En effet, en plus de fournir le minimum vital qui sont pour moi un designer WYSIWYG et une solution d'intégration du moteur de génération de documents (+ graphiques etc...), BIRT apporte des fonctionnalités étonnantes !

Par exemple, la possibilité d'être intégré très simplement dans une application RCP avec le BIRT Viewer ! Cette solution élégante permet notamment d'ajouter un côté "événementiel" fort convivial et pratique aux rapports de l'application. Il est possible d'afficher un rapport (un "état" pour les puristes) et sa table des matières dans colonne à gauche de l'écran avec un système de liens (ancres) sur chacun des titres un peu à la manière d'adobe viewer pour les fichiers PDF.

De plus, l'utilisation du BIRT Viewer permet d'ajouter au sein de vos rapports des liens vers d'autres rapports. C'est aussi la possibilité de paginer vos rapports et ce même au format HTML. Et pour finir, il est possible d'ajouter de l'interactivité (AJAX-like) aux rapports soit via du code javascript soit du code Java directement... Tout ceci peut en laisser rêveur quand on sait que le tout est bien entendu gratuit !

Les bons points qui me font écrire se billet sont:
-La communauté Eclipse qui héberge le projet (Birt Designer = plugin Eclipse ^^)
-Actuate dans l'ombre de BIRT ($$$)
-Une aide complète avec moult tutoriaux et exemples !
-Les possibilités d'extension de toute part du projet (ODA, Output Emitters, Birt Item...) pour ceux qui sont pressés et qui ont absolument besoin de certaines fonctionnalités manquantes à ce jour !
-Le libre choix du processus de génération et d'affichage des rapports (génération coté serveur ou client, render coté serveur ou client, fichier rptdocument transportable entre le client et le serveur si besoin pour externaliser l'affichage...)
-Des sous-rapports facilement gérables , testables et intégrables

Bon il y a certes quelques inconvénients quand même:
-La stabilité du designer qui peu parfois laisser perplexe le concepteur de rapport que j'ai pu être. (plantages réguliers sur différentes versions)
-Le codage style javascript pour prendre en entrée des objets javas (beans POJOs)
-Le manque d'input/output par rapport à d'autres framework de reporting à l'heure actuelle...
-La jeunesse du projet par rapport à d'autres...
-La lenteur de génération ?!

Les listes des atouts/défauts ne sont pas exhaustives... juste le reflet de mon retour d'expérience.

Wazaabi & Eclipse RCP

Eclipse RCP, un environnement de développement "utopique" :

Un des besoins récurrents chez les clients de type grand compte est de refondre leurs applicatifs métier réalisés avec des technos archaïques. Les raisons qui poussent les clients à refaire ce type d'application sont l'arrivée de nouveaux besoins, la nécessité d'interfacer les applicatifs, permettre une meilleure maintenabilité, augmenter l'ergonomie et j'en passe. Pour ce faire, une des solutions permettant de répondre tous les besoins est d'utiliser le framework d'Eclipse RCP ! Ce n'est pas la seule solution mais elle mérite d'être mise en avant son potentiel est intéressant.

Eclipse RCP permet très facilement de générer des applications clientes qui sont capables de communiquer avec un serveur distant. Avec des interfaces graphiques basées sur des composants propres au système d'exploitation exécutant, Eclipse RCP possède un véritable tookit de widgets standardisé, comme son nom l'indique (SWT = Standart Widget Toolkit). Accompagné de JFace, une surcouche à SWT, Eclipse RCP se dote d'un cadre de développement simple pour les composants dits "complexes" (les listes par exemple) mais c'est aussi une foultitude de fonctionnalités complémentaires: boites de dialogues, assistants, raccourcis clavier, undo/redo, filtres/tris... SWT s'occupe donc de fournir une bibliothèque de composants performants alors que JFace permet de simplifier la création des interfaces et offre un cadre de développement ainsi que des facilitant puissants !

Eclipse RCP c'est aussi et surtout le workbench d'Eclipse: ses vues, ses éditeurs, sa gestion des perspectives et ses fenêtres de préférence... Un atout considérable pour créer une application complexe ! Un environnement de travail ou les aspects principaux de l'application sont régis par des règles répondant à des besoins basiques. Ce framework, c'est aussi la gestion des plugins dont hérite une application de type Eclipse RCP, ce qui permet d'étendre des plugins existants ou de laisser la possibilité à d'autres d'utiliser son application, son plugin pardon...

Bien sur en choisissant Eclipse RCP, on prend ce qu'il y a de meilleur, c'est a dire l'environnement de développement d'Eclipse, l'IDE Java le plus aboutit à mon sens dont les performances et la maniabilité n'est plus a démontrer ! C'est notamment un facilitant de création pour les plugins Eclipse (RCP ou non) ou encore un assistant pour dessiner ses interfaces graphiques avec Visual Editor ! Utiliser Eclipse RCP c'est aussi "s'assurer" une compatibilité avec la batteries de projets Eclipse tel que BIRT, GEF etc...

Parlons de Wazaabi, un facilitant pour Eclipse RCP :

Je n'ai pas parlé des inconvénients d'Eclipse RCP... oui, comme tout ce qui existe, il y existe des inconvénients propres à Eclipse RCP ! Et la conception des interfaces graphiques en fait partie... En effet, un des avantages des applications web sur les clients riches type Eclipse RCP, est de pouvoir concevoir les écrans via un langages balisé comme l'HTML. Wazaabi est la pour combler ce manque ! Il permet de créer des interfaces graphiques en utilisant le langages XUL très proche du XML. Les fichiers XUL comme les fichiers HTML sont interprétés par un moteur de rendus pour générer visuellement les écrans ! Ceci permet de séparer la conception des écrans et les services métiers de l'application comme pour les clients légers en somme.

Pour résumer Wazaabi est une surcouche à Eclipse RCP qui est une alternative à l'utilisation de Visual Editor pour concevoir ses écrans. Ce framework permet notamment de mettre facilement en place l'internalisation des écrans depuis peu, et bientôt les feuilles de style. De plus, d'ici quelques temps un éditeur graphique permettra bientôt de concevoir les interfaces graphiques XUL... ce qui est tout de même un manque pour un facilitant dans ce même domaine mais passons... Un projet plein d'avenir qui a déjà été utilisé chez Leroy Merlin ainsi que chez Kiabi sur divers projets sur lesquels j'ai eu la chance de pouvoir m'impliquer.

Etre ingénieur en SSII

Une vision du consulting en SSII, parmi tant d'autres...

Depuis maintenant 1 an, j'occupe le poste d'ingénieur d'études et développement pour le compte d'une SSII à taille humaine (+/- 20 pers.) sur la métropole lilloise. Je pense avoir assez d'expérience pour tenter de la partager même si je suis bien conscient de manquer d'ancienneté dans ce métier pour faire une véritable analyse.

Le monde des SSII est souvent décrit comme rempli de dents longues où règne un climat malsain et où le profit est le maître mot ! Et bien laissez moi vous avouer la vérité: c'est VRAI ! Mais il faut développer ce propos et le nuancer pour se faire une idée réelle de ce qu'est le travail en SSII classique. Si vous commencez à lire ces lignes, merci d'aller jusqu'au bout de ma pensée.

Un monde sans scrupule ? Mais pas sans reproches !

Oui dans le monde des SSII, les consultants en sont réduits à être des pions placés par des commerciaux/managers de manière stratégique pour allier satisfaction client, bénéfice pour l'entreprise et épanouissement du collaborateur (notez bien l'ordre choisi). Ce n'est donc pas faux tout ce que l'on dit... mais réfléchissons 2min: Dans un monde ou le capitalisme atteint des sommets et ou la star'Ac et les médias font la loi, il faut arrêter de s'étonner quand, dans le tableau que je vous ai dressé plus haut, on rencontre des déçus et des anecdotes de fin malheureuse entre un consultant et une SSII quelconque... Bref, si vous vous engagez dans une SSII pour vous tourner les pouces, rebroussez chemins, on vous forcera à apprendre, on vous poussera au delà de vos capacités, on demandera d'être le meilleur, d'encaisser les "coups", d'être un caméléon, un espion et même parfois un menteur... Stoppons la langue de bois, en travaillant dans une société de service, on ne peux que vous demander d'être rentable !

Des collaborateurs délaissés... C'est faux !!!

Non, les consultants ne sont pas les laissés pour compte de la négociation SSII/Client. En effet, qui peut se plaindre d'avoir un supérieur nous demandant de nous surpasser, d'apprendre un peu plus chaque jour, d'avoir de multiples casquettes (technique, commerciale) et j'en passe... C'est en effet bien plus valorisant, même si c'est beaucoup plus fatiguant, d'avoir un poste de ce type que d'être un pion inutile dans un bureau reculé au fond d'un sombre couloir... Votre entreprise à besoin de vous et vous propose d'évoluer rapidement dans le sens qui vous va le mieux... Il suffit de faire savoir quels sont vos perspectives d'évolutions pour avoir un poste en corrélation avec votre demande... ce n'est pas immédiat mais si vous êtes à la hauteur, un manager préférera un collaborateur épanoui qui avance qu'un frustré qui trépigne... sur place.

Le revers de la médaille !

Parfois, souvent, rarement... tout est relatif. Toujours est il qu'il arrive que des consultants soient malheureux et se sentent rabaissés dans le petit monde du consulting. C'est sure que l'on entend régulièrement les consultants se plaindre de souffrir de leur condition de pseudo'intérimaire, condition qu'on leur rappelle trop souvent en clientèle où nous sommes souvent en décalage par rapport aux titulaires que l'on côtoie (avantages, statut, accès...) Mais est-ce que les titulaires peuvent se réjouir de participer 6 projets innovant et valorisants au sein de 3 grandes marques internationales sur une période de seulement 8 mois... j'en doute.

Comme dans tout il y a du pour et du contre dans le travail en SSII... le principal étant de piocher ce qui vous intéresse et d'encaisser sans rechigner sur ce qui vous rebute !

Formation : Ingénieur en Génie Informatique : IG2I, EC Lille

Formation : Ingénieur en Génie Informatique (IG2I, EC Lille)

2001-2006

Elève ingénieur à l’Institut de Génie Informatique et Industriel (IG2I) de Lens, Département de l’Ecole Centrale de Lille.
Informations : http://www.ig2i.fr et http://www.ec-lille.fr

2000-2001

Obtention du baccalauréat Scientifique option Sciences et Vie de la Terre (SVT) spécialité Mathématiques au Lycée Louis Armand à Eaubonne (95 – Val d’Oise).

Téléchargez mon CV au format PDF ou WORD.