Nous ne comptons plus les fois où nous avons été sollicités par des PME ou des ETI pour regarder le code d’un système d’information développé par une seule personne #OperationBoiteNoire ! Alors est-ce un pari gagnant que d’internaliser un développeur ou de se reposer sur un freelance pour réaliser ses applications web 🤔 ? A première vue, on pourrait croire que cette approche va vous permettre de maîtriser vos coûts et de faciliter votre gestion de projet en ayant un seul interlocuteur mais attention aux effets de bord 👻 !

Faites-vous la course à l’économie ?

Vous êtes joueur 🎰 ? Vous êtes peut-être même du genre à tout miser sur un seul numéro à la roulette 🙈 ? Dans ce cas, il est probable que vous ayez un seul développeur en charge de votre SI 😉 ! Nous pouvons supposer que le choix d’un développeur unique est motivé par la réduction des coûts de développements. Il est vrai que l’informatique représente des investissements importants et il est normal de chercher à en diminuer la charge. Cependant, le travail avec un développeur unique est loin d’être une garantie d’économie et cela s’avère même généralement contreproductif…

En premier lieu, si vous misez tout sur une personne, soyez certain qu’elle a le niveau et l’expérience 🏅 ! L’informatique est un domaine où de grandes disparités de niveaux entre les développeurs persistent. Faites-vous vraiment une bonne affaire si votre prestataire est plus lent que la moyenne avec un taux jour homme attractif (ou un développeur incapable de résoudre certains problèmes ou de faire certaines abstractions) ? Ces questions posent la problématique du contrôle du travail d’un développeur unique pour éviter de surpayer vos développements en pensant faire une bonne affaire.

Par ailleurs, la construction d’un système d’information performant est une affaire au long cours 🏗 ; le gain à court terme qui nécessite in fine des investissements plus importants à long terme est un écueil assez fréquent 😨. Vous devez donc vérifier les possibilités d’évolution de vos développements pour éviter d’entrer dans un cycle de refontes de vos applications – en l’absence d’un socle évolutif – qui engendra mécaniquement des coûts plus élevés et vous empêchera d’innover pour prendre un temps d’avance sur votre marché (vous serez toujours en train de refondre les fonctionnalités de base).

Enfin, la logique d’internaliser des compétences chez vous est saine mais nous vous conseillons fortement d’internaliser un poste de chef de projet digital 🤓 pour faire la jonction entre vos besoins métiers et le ou les développeurs. Cette approche vous permet de cadrer les travaux et d’apporter une vision long terme pour rentabiliser vos projets 🔭. De manière analogue, vous pouvez prévoir un projet d’aménagement de votre logement comme le chef de projet prévoit les fonctionnalités de votre SI. Cependant, il ne vous viendrait jamais à l’idée d’ouvrir un mur porteur vous-même mais vous solliciterez un ou des experts. Et bien, pour le développement web, c’est pareil !

Est-ce que vous comprenez pourquoi nous avons comparé le choix de travailler avec un développeur unique à l’idée de tout miser sur un seul numéro à la roulette ? Il existe une multitude de niveaux d’expertise pour les développeurs, vous aurez certainement beaucoup de difficultés à évaluer celui de votre développeur unique 👽, aussi la « chance » de tomber sur la perle rare est très minime et en cas d’erreur vous aurez fait une fausse bonne affaire.

Respectez-vous les standards de développement ?

Maintenant partons de l’hypothèse que vous avez la « chance » de travailler avec un « super développeur » (oui ça existe). Au risque de paraître pessimiste cela ne garantit pas encore le succès de votre projet (désolé)…

Tout d’abord, définissons ce qui correspond à un succès ? Chez Agilap, nous considérons que le succès d’un projet se mesure à son impact « business » (votre SI a-t-il un effet levier sur votre activité ?) et à son évolutivité. L’évolutivité peut être vue sous deux angles :  la possibilité pour un nouveau développeur de s’intégrer au projet rapidement et la possibilité de faire évoluer facilement le projet. Pour garantir un bon niveau d’évolutivité nous considérons qu’il faut à minima travailler sur des frameworks de développements connus 😎 (ex. Symfony ou ou React etc.), respecter les bonnes pratiques : conventions de nommages, par exemple, pour rendre évident certaines parties du code (organisation des fichiers et utilité des variables), commenter son code à l’attention d’autres développeurs, et idéalement utiliser l’intégration continue (cf notre article « C’est quoi le développement web durable ? »). Cette évolutivité repose donc sur le respect des standards de développement. Elle est la garantie qu’aucun de vos développements ne sera inutile et que vous allez améliorer la performance de votre SI d’année en année 💪.

Ceci étant dit, lorsqu’un développeur travaille seul, il est peu probable qu’il suive pour lui-même les bonnes pratiques de développement (« seriously » mes amis développeurs (!), vous suivez les bonnes pratiques dans votre « side project » perso 🤔 ?). Je ne doute pas de la bonne volonté de tous les développeurs mais le développeur seul va rapidement prendre des raccourcis, un manque de découpage des fichiers, des commentaires trop rares parce qu’il connaît bien son code, la mise en place de librairies obscures pour traiter certaines fonctionnalités parce qu’il les connait… Plus vous avancez dans le temps et plus votre développeur unique 👽 sera la seule personne capable de maintenir votre application. Si vous arrivez à ce stade, vous êtes donc devenus dépendants de votre développeur et nous vous conseillons de ne pas le froisser 😉. Et oui, que se passe-t-il si votre développeur part faire le tour du monde ? Ou s’il a un accident de la vie ? Êtes-vous prêt, si besoin, à repartir de zéro pour reconstruire votre SI ?

Le paradoxe est que le développeur qui arrive à maintenir un SI que lui seul peut comprendre développe généralement un égo sur dimensionné… Il est le seul à comprendre le fonctionnement du SI parce que les autres ne sont pas bons (CQFD), mais non pas parce qu’il n’a pas respecté les standards de développement ^^. Ces développeurs deviennent en quelques sortes des Pr Raoult ou des Jean-Claude Van Damme du code ! Et attention au syndrome de « ceux qui en parlent le plus et en codent le moins bien »… Si vous arrivez à ce stade, vous n’aurez plus de réelle visibilité sur les développements et votre développeur sera autant chez vous que vous ! On espère que c’est votre meilleur ami 💑 (bon généralement les développeurs sont cools) !

Pouvez-vous imposer un travail en équipe ?

Pour schématiser et reprendre notre définition du succès d’un projet, vous êtes responsable de mesurer l’impact business de votre SI et votre développeur est responsable de le rendre évolutif.

Si votre SI a pris de l’importance et que vous vous retrouvez dans une situation de dépendance vis à vis de votre développeur, vous avez encore une possibilité de sauver vos investissements, il faut contraindre votre développeur à travailler en équipe. En effet, vous aurez besoin de trouver une nouvelle personne pour « renforcer » l’équipe de développement, si possible expérimentée (voir très expérimentée), et qui va faire de manière indirecte un audit de l’évolutivité de votre SI en « essayant » de travailler dessus. Vous aurez un retour très rapidement du niveau d’évolutivité de votre SI par le nouveau développeur sur sa capacité à faire évoluer le projet.

Au-delà du changement de manière de travailler que va provoquer l’arrivée d’un ou plusieurs développeurs nouveaux sur le projet, vous devrez gérer la probable résistance au changement de votre développeur unique 👽. Et attention, il connaît très bien vos équipes et va les persuader qu’il ne faut pas changer pour leur intérêt (c’est du vécu), ne vous laissez pas influencer car vous perdriez le bénéfice d’une belle manœuvre pour reprendre la main ! A ce stade, il va même surement vous menacer d’arrêter le projet « parce qu’il en a marre » et « qu’il serait ravi de passer la main ». En réalité, c’est du bluff (!), vous représentez sûrement sa plus grosse source de revenu et il connaît parfaitement votre dépendance vis à vis de sa connaissance du projet. Il vous met la pression car en cas de rupture il sait qu’il vous met en difficulté, il est le seul à avoir accès au code, à connaître l’architecture, à gérer l’hébergement, à donner les droits d’accès etc. Notre conseil dans cette situation est de prendre une posture « Candide », rassurez votre développeur unique en lui disant que vous avez besoin de lui mais que vous souhaitez accélérer et que vous avez besoin de « renforcer » « l’équipe de développement ». Ne critiquez surtout pas son travail même si vous commencez à avoir des retours plus ou moins positifs! Et s’il insiste sur un potentiel départ, dites-lui que vous êtes d’accord mais que ça ne peut pas être envisageable à court terme tant que la continuité des projets n’est pas assurée. Votre développeur unique a peur du travail en équipe 😱 car il a peur d’être jugé sur la qualité de son travail alors que jusqu’à présent il était le Dieu 🌞 de la tech chez vous !

Lorsque le travail en équipe sera un fait accompli, soit votre développeur unique sera en porte à faux et partira de lui-même, soit il va saisir cette chance – s’il est intelligent – de sortir de son isolement et d’être de nouveau challengé par ses « nouveaux » pairs pour redevenir  moteur sur le projet. Dans tous les cas vous aurez pérennisé vos investissements et vous pourrez lancer les projets innovants qui vous permettront de gagner des parts de marché 🏆 !

Vous êtes confrontés à ce genre de situation ? Vous avez besoin d’aide ? N’hésitez pas à nous appeler pour en parler au 01 84 25 73 20 ou à compléter notre formulaire de projet ici 😉.

Bons projets et à bientôt, l’équipe d’Agilap 🌈