Discussion :

[smeden]

Bonjour,
Nouvellement inscrite sur ce forum, je m'adresse à vous pour quelques conseils sur la façon de procéder dans ma situation. Je m'explique, je travaille depuis plusieurs années avec un prestataire qui nous a développé un progiciel métier en langage C++ sous Borland 6. Il s'agit d'une interface de saisie qui alimente une base Postgre/postgis. Ce prestataire vient de me faire savoir qu'il n'assurera plus la maintenance à partir du 1er janvier (fin de contrat) et qu'il ne pourra plus répondre à nos besoins de développement futurs.
En interne, nous n'avons absolument pas de compétences dans le domaine et ce progiciel est au cœur de nos activités. Il me faut donc trouver rapidement une solution pour la maintenance et même pour du développement car nous comptions faire évoluer le progiciel dans les mois à venir.
Alors voilà mes interrogations :
- est-il facile de retrouver un prestataire qui reprendra la suite et comment le recruter (annuaire, réseau...) ?
- envisager un recrutement est-il une solution réaliste sachant que dans l'idéal il faudrait que la personne ait également quelques connaissances en SIG et/ou gestion de base de données Postgre ? Si oui, quelle niveau d'étude viser, quel niveau de rémunération envisager et comment procéder pour le recrutement ?

Bon voilà pour mon problème du moment. Précision, nous sommes situés dans le Nord-Pas-de-Calais.

J'espère avoir posté au bon endroit sur le forum, et merci d'avance pour vos éclairages experts.

[imperio]

- est-il facile de retrouver un prestataire qui reprendra la suite et comment le recruter (annuaire, réseau...) ?

Pour ce qui est de recruter, pleins de sites internet le permettent. Faire une annonce dans un media plus "traditionnel" vous attirera sans doute aussi des candidats.

[smeden]

Merci pour votre réponse.
Si je posais les questions ici c'est pour avoir les avis de "spécialistes" et être plus efficace dans mes démarches, soit pour rechercher au plus vite un prestataire, soit pour trouver quelqu'un de compétent. C'est pour vous peut-être évident mais quand ce n'est absolument pas votre domaine d'activité, ce n'est pas si simple.
Bon week-end à tous

[imperio]

A vrai dire, je vous ai donne les lieux ou je cherchais moi-meme quand j'etais a la recherche d'un CDD. Je me suis dit que si vous postiez dans ce genre d'endroits cela vous aiderz peut-etre.

En ce qui concerne le nombre d'annees de formations necessaires a accomplir la maintenance de votre logiciel, c'est assez difficile a dire et comme ce n'est pas mon domaine je prefere ne pas m'avancer. Dans notre secteur encore plus qu'un autre car plutot jeune encore, le diplome ne signifie pas forcement competence.

Bonne chance.

[smeden]

Merci en tout cas de votre intérêt porté à mon message et bon week-end à tous

[JolyLoic]

Savoir s'il vaut mieux un recrutement ou un autre prestataire n'est pas évident. Un informaticien seul dans un structure risque de ne pas être aisé à gérer, surtout si vous n'y connaissez rien dans le domaine...

La description que vous faites en 2 mots du produit (quelques détails en plus seraient nécessaire pour doner un avis qui soit plus que de la devinette) ne le classe pas dans les choses les plus difficiles. Après, tout est question de taille. Une application simple devient complexe au fur et à mesure que sa taille croît.

Les techniques que vous utilisez sont aussi assez vieilles (d'où la difficulté de trouver un prestataire, et peut-être aussi de recruter). Ça va jouer sur la difficulté de maintenance, mais aussi sur la motivation d'un éventuel candidat.

Pour tout dire, il s'agit à première vue du type de produit que l'on ne développe plus trop en C++ de nos jours (on réserve le C++ à des produits où les performances comptent plus que le coût de développement), ce qui fait que vous aurez du mal à trouver des bibliothèques compatibles (ces bibliothèques de composant déjà faits sont indispensable pour développer du code robuste avec des coûts ou des délais raisonnables). Vous dites que vous désirez apporter de grosses modifications dans un futur proche, peut-être faudra-t-il aussi envisager une transition technologique.

[oodini]

Borland 6 étant une technologie aujourd'hui assez ancienne (10 ans), vous devrez vous adresser à quelqu'un qui a sans doute assez d'expérience. Et un développeur ayant toujours à cœur de mettre à jour ses compétences, il va falloir le motiver pour bosser sur Borland 6. Surtout que les compilateurs de Borland (aujourd'hui Embarcadero Technologies) ne sont pas vraiment à la mode.

La solution peut alors être tout refaire en un autre langage (pourquoi pas en Python ?). Ce challenge sera plus intéressant pour votre prestataire, et c'est l'occasion pour vous de vous repencher sur les spécifications de ce progiciel.

Mais la pertinence de cette solution dépend beaucoup de la taille du projet, et donc de son coût...

Sinon, il existe sur ce site une section dédiée à l'environnement C++ Builder. Ceux qui le fréquentent sont sans doute les mieux placés pour vous répondre.

[koala01]

Salut,

- est-il facile de retrouver un prestataire qui reprendra la suite et comment le recruter (annuaire, réseau...) ?

Si personne ne connait rien au développement dans ta boite, il sera difficile de recruter "un bon" prestataire

J'aurais tendance à te conseiller de faire jouer ton réseau (il y a sûrement quelqu'un qui connaît quelqu'un qui connaît la perle rare )

- envisager un recrutement est-il une solution réaliste sachant que dans l'idéal il faudrait que la personne ait également quelques connaissances en SIG et/ou gestion de base de données Postgre ?

Réaliste, peut être (bien qu'il sera peut être difficile de gérer un développeur qui travaille en "roue libre"). Quant à savoir si c'est réalisable, cela dépendra de beaucoup de choses

Si oui, quelle niveau d'étude viser,

Personnellement, je suis contre le fait de viser un niveau d'étude particulier.

Un développeur expérimenté qui est capable de se remettre en question, qui accepte de s'investir dans son boulot (ce qui implique, parfois, le fait de se former lui-même à certaines techniques ) sera souvent bien plus compétant qu'un bac +5, bac+7 tout frais sorti de l'école mais qui n'a jamais mis les mains dans la cambouis.

Personnellement, je n'ai "qu'un malheureux" bac+3, mais je me considère particulièrement compétant dans tous les domaines liés au développement (de l'analyse des besoins à l'intégration en passant par la conception et la mise en oeuvre). En tout état de cause, j'ai eu de nombreuses discussion avec des gens soit disant bien plus qualifiés que moi, sur papier, qui m'ont fait douter de leur compétence à eux (et je ne crois pas que l'on trouvera beaucoup de monde pour me contredire )

quel niveau de rémunération envisager

Là, on touche une code sensible, car, de toute évidence, si tu envisages le recrutement, c'est pour lui donner l'ensemble des responsabilités qui échoient normalement à une équipe complète.

Tu risques donc d'être confrontée à des réponses proches de

A grande responsabilité, grand salaire

Personnellement, j'estime qu'une situation où je jouerais à la fois le rôle d'analyste fonctionnel, d'analyste technique, de développeur, de testeur et d'intégrateur devrait m'apporter un salaire d'à peu près 2500€ nets par mois (Enfin, ce serait une base de discussion raisonnable, à moduler en fonction des distances à parcourir, des facilités d'accès et des avantages extra légaux )

et comment procéder pour le recrutement ?

Hummm... Sans rien connaître en programmation, c'est particulièrement difficile :

Comme pour tout recrutement, ce sera très fort une question de "feeling", mais il ne t'aidera absolument pas à discerner les candidats qui ont simplement de la tchatche de ceux qui sont réellement compétents

La facilité dont le candidat fait preuve pour arriver à expliquer simplement certains aspects peut être un critère, mais il ne servira à rien si le candidat n'est pas capable d'appliquer ce qu'il explique si bien

Tu peux, éventuellement, t'orienter vers des "chasseurs de tête spécialisés" qui feront une pré sélection pour toi, mais encore faut il "tomber" sur l'un de ceux qui tente réellement de satisfaire les besoins du client et qui n'envoie pas en priorité le "profil qui leur rapportera le plus"

Quoi qu'il en soit, je conseillerais de faire en sorte que la procédure de recrutement prenne le moins de temps possible, et d'utiliser au mieux les périodes d'essais : A défaut de trouver tout de suite "le bon" développeur, cela te permettra sans doute de ne pas devoir choisir entre garder quelqu'un qui "ne convient pas tout à fait (ou pas du tout )" et n'avoir plus personne pour faire le travail.

Ceci dit, que tu t'orientes vers un prestataire de service ou vers un recrutement, il y a de nombreux points qui devraient être abordés.

Par exemple, la facilité avec laquelle l'un comme l'autre pourront "s'approprier" le projet (je veux dire : la facilité avec laquelle ils seront en mesure d'intervenir sur le projet, et non celle avec laquelle ils arriveront à prétendre que c'est "leur" projet ) dépendra fortement de l'état du code et de la possibilité de disposer de l'historique.

• Y a-t-il une analyse à jour et complète du projet
• Y a-t-il un historique des bugs, des améliorations et des évolutions suivies par le projet
• Existe-t-il des tests unitaires pour les fonctions principales
• Existe-t-il une sorte quelconque de documentation de développement
• Quelle est la taille du projet en l'état est-on plus proche des 150 000 ou des 3 000 000 de lignes
• Depuis combien de temps ce projet est-il en développement A-t-il déjà subi des évolutions majeures (passage de BCB5 à BCB6, par exemple) Si oui, y a-t-il eu des problèmes majeurs

sont autant de questions dont la réponse influera énormément sur la facilité avec laquelle le projet sera repris.

Je suis en outre tout à fait de l'avis de oodini au moins sur le fait que BCB6 est particulièrement vieux et sur le fait qu'une refonte avec une approche moderne (pas forcément en C++, mais contrairement à JolyLoic, je ne crois pas que ce langage soit moins adaptés qu'un autre) pourrait peut-être s'avérer moins coûteuse au final.
Mais d'autres questions devraient être posées pour arriver à le déterminer, comme:

• Pourquoi C++
• Pourquoi Borland
• Pourquoi PostGre
• Quelle taille a la DB (nombre de tables, nombre d'enregistrement moyen, ...)
• En l'état et en limitant les interventions à la maintenance, s'il s'agissait de "tout reprendre à zéro", combien de temps pourrais tu attendre

Bref, beaucoup des questions que tu poses nécessitent plusieurs éclaircissements avant d'être en mesure de répondre, mais, de manière générale, qu'il s'agisse d'un prestataire ou d'un développeur "interne", le mieux est sans doute de faire en sorte d'assurer un "roulement rapide" au cas où il ne conviendrait pas car, sans connaissance en informatique, il y a vraiment peu de chances que tu tombes sur "le bon" au premier essai

[smeden]

Merci pour vos réponses qui me donnent des éléments intéressants.
Je retiens principalement la relative obsolescence du produit. Mais je crois que pour le moment on n'a pas trop le choix de continuer avec dans l'immédiat.
Et donc difficulté de trouver la personne qui pourra s'adapter à ces techniques vieillissantes. Ceci dit, une fois la personne en place on sera bien plus capable d'avoir un avis technique qui tienne la route sur l'évolution à prévoir.
Pour le recrutement, j'entends bien que ce n'est pas uniquement une question de niveau d'études. Je pense en effet qu'il vaut mieux un bon autodidacte sans diplôme qui est souvent quelqu'un de particulièrement motivé qu'un "grand" diplômé peu motivé et moins investi dans ce qu'il fait. Seulement qui dit recrutement dit salaire et c'est souvent adossé à un niveau d'études pour les estimatifs. Ma question n'était pas pour obligatoirement exigé un niveau d'études mais plutôt pour estimé le salaire à prévoir.
J'ai noté toutes les questions techniques à se poser qui m'aideront pour les discussions avec mon prestataire avant la fin du contrat et pour poursuivre dans les meilleures conditions possibles.
Bonne fin de journée à tous

[koala01]

Merci pour vos réponses qui me donnent des éléments intéressants.
Je retiens principalement la relative obsolescence du produit. Mais je crois que pour le moment on n'a pas trop le choix de continuer avec dans l'immédiat.

Humm... à voir...

Il y a quantité de possibilités entre celle qui consiste à continuer "contre vents et marées" le développement avec les outils utilisés pour l'instant et celle qui consiste à reprendre le développement "from scratch".

Le juste milieu est -- peut être -- de prévoir une "maintenance minimale" (correction de bugs, évolutions "mineures" ) de l'existant pendant que le gros du travail consiste à reprendre un développement correct sur base de l'analyse existante.

Ce n'est pas forcément parce que le projet a été développé sur dix ans qu'il faudra forcément attendre dix ans de plus pour arriver à un résultat équivalent s'il existe une analyse fonctionnelle correcte et compréhensible, si le développeur (qu'il soit interne ou non) peut s'appuyer sur des gens qui connaissent le "business" et s'il "suffit" de convertir certaines technologies.

D'un autre coté, s'il n'existe qu'une analyse fonctionnelle fragmentaire, non tenue à jour, si le développeur est systématiquement confronté à des réponses proches de "bah, je ne sais pas, c'est peut être..." lorsqu'il pose des question sur le business ou sur l'organisation générale, si les spécificités de BCB6 (dont l'utilisation de la vcl) ont été imbriquées trop intensément au niveau des données métier, la situation inverse est tout aussi envisageable : il est possible que le fait de tout reprendre "from scratch" mette plus de temps que tout le temps durant lequel le projet d'origine a été développé (parce qu'il faudra passer énormément de temps à trouver "la" réponse qui a été faite face à certaines situation ) .

Mais ce sont là deux hypothèses extrêmes et il y a des chances (mais il faudrait voir l'état du projet actuel pour se faire une idée) que la réalité se situe "quelque part" entre les deux

Vient alors le fait que tu envisages de faire évoluer le système dans les mois à venir :

Toute la question sera de savoir s'il est préférable de prendre directement cette évolution en compte pour l'intégrer directement ou s'il faut un "minimum vital" pour être en mesure de l'intégrer et de savoir si cette évolution est urgente, parce qu'il y a une "deadline" à respecter impérativement ou si cette évolution peut être "reportée à un délais raisonnable" (sous entendu : jusqu'à ce que le projet de remplacement soit utilisable).

Et donc difficulté de trouver la personne qui pourra s'adapter à ces techniques vieillissantes. Ceci dit, une fois la personne en place on sera bien plus capable d'avoir un avis technique qui tienne la route sur l'évolution à prévoir.

Très certainement.

Mais il faut bien prendre conscience qu'il faudra, de toutes manières, un certain temps au développeur pour s'approprier le projet.

Il n'est pas excessif de compter un à deux mois, même si le développeur maîtrise les technologies utilisées, pour qu'il commence à en appréhender les différents aspects.

Et ce délais semble être réellement minimal... Si le projet est complexe, il peut assez facilement être doublé voire triplé (ou plus encore )

Pour le recrutement, j'entends bien que ce n'est pas uniquement une question de niveau d'études. Je pense en effet qu'il vaut mieux un bon autodidacte sans diplôme qui est souvent quelqu'un de particulièrement motivé qu'un "grand" diplômé peu motivé et moins investi dans ce qu'il fait. Seulement qui dit recrutement dit salaire et c'est souvent adossé à un niveau d'études pour les estimatifs. Ma question n'était pas pour obligatoirement exigé un niveau d'études mais plutôt pour estimé le salaire à prévoir.

Face à un prestataire, l'idéal (de ton point de vue du moins) est peut être d'envisager le forfait : Vous vous mettez d'accord sur un travail à effectuer, sur les délais de livraison et sur la somme à verser (selon des modalités à convenir) en contre partie.

Il est tout à fait possible d'envisager un forfait "développement" et un forfait "maintenance"

A charge pour le prestataire de faire en sorte de respecter ses obligations.

L'avantage est que cela évite des surprises financières: tu sais ce que tu payes (ou va payer) et tu sais ce que tu vas recevoir au final.

L’inconvénient est qu'il faudra être particulièrement précis et complet dans tes demandes.

Car il faut te dire que, le but du prestataire sera alors de faire en sorte de gagner un maximum en en faisant me moins possible

Pour le développeur interne, c'est un statu d'employé ou de cadre (pas forcément de cadre supérieur, mais de cadre quand même) et, comme son boulot touche quand même au nerf de tout ton business, un salaire en conséquence n'est pas forcément cher payé pour un "bon" (mais est clairement surpayé pour un "mauvais" )

[Iradrille]

Et ce délais semble être réellement minimal... Si le projet est complexe, il peut assez facilement être doublé voire triplé (ou plus encore )

...

L’inconvénient est qu'il faudra être particulièrement précis et complet dans tes demandes.

Car il faut te dire que, le but du prestataire sera alors de faire en sorte de gagner un maximum en en faisant me moins possible

Petite précision sur le terme "complexe" : ce n'a pas grand chose à voir avec ce que fait exactement le logiciel, mais plus la façon dont il le fait. Un logiciel mal codé, possédant énormément de lignes de code, mal commenté etc.. est complexe et dur à prendre en main.

Pour les prestataires je confirme, je suis étudiant (plus pour longtemps o/) et en cours on nous apprend à faire le minimum vital, à vraiment faire un code très peu extensible etc.. dans ces cas là (maximiser les gains à court terme...).

Un autre problème des prestataires est que généralement on achète un logiciel avec 2 ou 5 ans de support, et qu'après on doit se démerder avec (et trouver quelqu'un pour le reprendre n'est pas forcément simple).

Bref il faut faire attention à ça.

Mais, et surtout si ta boite n'a rien à voir avec le dev (ce qui semble être le cas) la prestation est ce qui reviendra au moins cher.

[oodini]

Pour les prestataires je confirme, je suis étudiant (plus pour longtemps o/) et en cours on nous apprend à faire le minimum vital, à vraiment faire un code très peu extensible etc.. dans ces cas là (maximiser les gains à court terme...).

Moi qui me désespère de cette façon de travailler, j'apprends aujourd'hui grâce à toi que c'est enseigné dans les écoles d'info... Je crois que je vais aller me pendre avec un câble RJ45.

[Ehonn]

Remarque : Dans certains cas, le minimum vital est plus court, plus simple, plus compréhensible (utilisation de bibliothèques par exemple) et donc plus facilement extensible
(Faire le minimum vital ne veut pas dire tout mettre dans une seule fonction et/ou tout coder à la main)

[koala01]

Moi qui me désespère de cette façon de travailler, j'apprends aujourd'hui grâce à toi que c'est enseigné dans les écoles d'info... Je crois que je vais aller me pendre avec un câble RJ45.

Bah, tu sais, dans le système actuel, il n'y a rien de nouveau sous le soleil : tant que l'argent sera le nerf de la guerre, les gens feront toujours tout pour en avoir un maximum au prix d'un effort minimum

Ceci dit, on peut effectivement ne pas être d'accord avec le principe de faire un code peu extensible, car cela signifie de privilégier les bénéfices à court termes au risque d'occasionner de lourdes pertes à long terme (car, si évolution il y a, tu y passeras plus de temps).

Mais, pour ce qui est du fait de faire le minimum vital, c'est une politique qui -- quand elle est correctement appliquée -- présente des avantages. Elle t'incite en effet :

• à ne pas réinventer la roue
• à réfléchir avant de te lancer sur le clavier et à vomir ton code
• à ne pas te lancer dans le développement de fonctionnalités dont tu n'as pas encore besoin et qui risqueraient de rentrer en conflit avec des évolutions futures
• à faire en sorte que ton code soit facilement compréhensible

Bref, tout le contraire d'un code difficilement maintenable

Par définition, un bon développeur est un développeur paresseux : Il s'arrangera en effet pour en faire le moins possible, ce qui implique qu'il devrait s'arranger pour limiter les risques de devoir revenir sur ce qu'il a codé

[oodini]

Le minimum vital évoqué par Iradrille me semblait plus faire référence à son paragraphe précédent, pas aux bon principes que vous rappelez.

Cela entre en outre en résonance avec une conférence à laquelle j'ai assisté hier sur les risques psychosociaux aux travail. Un des facteurs de stress identifié est la différence d'exigence qualitative entre un salarié et son donneur d'ordre. Le salarié considérant généralement que le fruit de son travail est un reflet de sa personnalité, il vit assez mal qu'on lui demande de se mettre en "mode dégradé" (chercher "Les conflits de valeurs" dans ce document).

[koala01]

Le minimum vital évoqué par Iradrille me semblait plus faire référence à son paragraphe précédent, pas aux bon principes que vous rappelez.

Cela entre en outre en résonance avec une conférence à laquelle j'ai assisté hier sur les risques psychosociaux aux travail. Un des facteurs de stress identifié est la différence d'exigence qualitative entre un salarié et son donneur d'ordre. Le salarié considérant généralement que le fruit de son travail est un reflet de sa personnalité, il vit assez mal qu'on lui demande de se mettre en "mode dégradé" (chercher "Les conflits de valeurs" dans ce document).

Il y a très certainement de cela

Et je crois qu'en fait, le gros problème vient souvent du fait que les ordres émanent d'avantage d'un financier que de quelqu'un qui sait ce qu'implique le développement.

Ceci dit, un développement de qualité n'est pas forcément synonyme de développement cher, même à court terme.

J'ai l'habitude, lorsque je suis confronté à une solution qui refuse obstinément de montrer le bout de son nez, de quitter mon poste de travail, d'aller boire un café, fumer une cigarette ou prendre un bol d'air frais (ou parfois les trois d'ailleurs ) .

Un non développeur (ou un financier pur et dur) aura du mal à concevoir le fait que ces cinq minutes de pause me permettent bien souvent de trouver la solution tant recherchée simplement parce que cela me fait sortir le nez de la m...e dans laquelle je me trouve.

Le même non développeur ou financier pur et dur aura du mal à comprendre que, si l'on se "pose" cinq minutes pour réfléchir à la situation, le code qui en résultera sera plus rapidement écrit, plus compréhensible et de meilleure qualité (de manière générale) et que, même sur le court terme on regagne très facilement le temps passé à la réflexion.

S'il est vrai que l'étape finale (l'écriture du code en lui-même) s'apparente peu ou prou à du "simple travail de dactylographie / traduction" (bien que ces deux travaux ne soient en réalité pas si simples que cela ) il est tout à fait faux de croire qu'un développeur, même s'il se contente d'appliquer les décisions prises par d'autres (peut être plus qualifiés que lui) n'est qu'un simple "pisseur de code".

Le développement de manière générale est beaucoup plus complexe que cela

[Iradrille]

Le minimum vital évoqué par Iradrille me semblait plus faire référence à son paragraphe précédent, pas aux bon principes que vous rappelez.

Par minimum vital j'entend ne faire aucune abstraction "inutile", faire un code absolument pas réutilisable ni facilement extensible.

Exemple : écrire un algo qui force l'utilisation d'un type de conteneur particulier, même si en écrivant l'algo, le conteneur choisi semble le meilleur, ça peut poser des problèmes (de performance principalement) si l'algo doit changer / évoluer.

@koala01 la pause café / clope quand on bloque sur quelque chose est tellement utile pour se vider l'esprit et permettre d’aborder le problème sous un autre angle que ça devrait être obligatoire.

[smeden]

Merci vraiment de l'intérêt que vous portez à ma problématique. Plus je vous lis et plus je pense que l'embauche serait LA solution. Ca permettrait à un spécialiste de juger objectivement de l'évolution à prévoir pour notre outil, en procédant à une maintenance minimale dans un 1er temps histoire de s'approprier les choses. C'est vraiment pas facile de se faire un avis quand on n'a aucune compétence en interne. Ca nous rend extrêmement dépendants des conseils de personnes extérieures qui sont bien souvent peu objectives. D'où l'intérêt des présents échanges qui donnent un regard extérieur à priori non intéressé (je veux dire financièrement).
J'entends bien l'argument qu'une prestation de maintenance couterait moins cher mais cela me semble être un calcul à court terme qui ne prend pas en compte l'évolution future et néglige par ailleurs les apports de la personne recrutée au sein de la boîte en termes de compétences informatiques plus généraliste.
Me reste à résoudre 2 problèmes : convaincre mon Président et ça n'est pas gagné dans la conjoncture actuelle. Et si j'y parviens, trouver la perle rare. Sur ce 2ème point, si vous avez des pistes (sites spécialisés, asso d'anciens élèves, contact d'écoles ou universités...).

[oodini]

Compétences techniques mises à part, vous aurez besoin de quelqu'un qui ne s'en va pas au bout de 2 ans. Privilégier quelqu'un qui recherche un poste stable (du fait de contraintes familiales, par exemple).

Et la dimension humaine sera importante : ce développeur devra avoir de bonnes et fréquentes relations avec les personnes définissant le fonctionnel.

[smeden]

Oui Oodini ce sont des critères importants en effet. Pour ce qui est du relationnel, ça devrait bien se passer (si c'est quelqu'un d'ouvert et de sociable bien sur). Pour la stabilité, c'est à voir mais peut-être vaut il mieux avoir une personne avec un peu moins d'expérience mais qui sera susceptible de rester plus longtemps.