Travailler avec des développeurs quand on n’en est pas un

Vous devez gérer un projet dans lequel il va y avoir des développements externes et vous n’avez pas d’expérience dans le développement de code ? Comment parler avez des développeurs quand on n’en n’est pas un ? Et comment voir quand une boite développement se paye votre tête ou que l’on leur demande vraiment l’impossible ? Quelques pistes dans un article bien trop long.

Publié le

Je tire cette analyse sur mon expérience personnelle, et je pense que cet article concerne aussi bien les développeurs qui doivent travailler avec des « gens normaux », comme des clients-qui-payent, que les responsables d’exploitation/technique qui ont un besoin de faire-faire développer des choses. Et ce, pas forcément en lien avec l’audiovisuel.

Quand on écrit du code on doit conceptualiser un château fort dans sa tête pour le transcrire en instructions simples, en texte qui, au moment de l’exécution du programme vont faire « vivre quelque chose » dans une machine ou un serveur, qui devrait ressembler du mieux possible au château fort que l’on a imaginé au départ.

A moins d’être un vrai génie, et il y en a, on ne peut pas conceptualiser dans sa tête l’ensemble du château fort, comme la position des fenêtres, les tuiles, le nombre de marches… Et comme tous les développeurs ne sont pas tous des génies et ont leurs limites de concentration et de mémorisation, le château sera pensé par morceaux, par parties, et sera monté et ajusté au fur et à mesure de sa construction. Parfois on reculera, on cassera un morceau pour le reconstruire mieux, etc. Et à la fin, il devrait être assez solide pour tenir des siècles. Et rester entier.
Pourquoi l’image du château fort ?

Parce que le code produit doit donner une application qui :

  • Résiste au temps, on ne va pas revenir dessus toutes les semaines une fois le projet terminé.
  • Résiste aux utilisateurs, et leurs innombrables tentatives involontaires de casser quelque chose en entrant par exemple une date en toutes lettres dans un champ numérique ou une adresse avec des caractères Japonais.
  • Résiste aux aléas du matériel, comme un câble réseau débranché et tout le process métier tombe par terre. Franchement, qui trouverai ça normal ?
  • Résiste aux pirates et autres curieux qui aimeraient bien aspirer votre savoir-faire et vos ressources, voire vous empêcher de travailler.
  • Stocke vos récoltes, enfin vos process métiers, vos données client… à l’abri des fléaux.
  • Et il existe des architectes logiciels pour aider à la conception et la façon dont les entités vont travailler ensemble, c’est dire si la comparaison se tient !

Bref un bon développement est meilleur quand il se rapproche d’une structure pensé solide et durable. Après, si vous commandez un château fort au prix d’un abri de jardin, ne vous étonnez pas que votre toit soit dans un plastique qui va fuir dans 3 ans ! Il y a une corrélation directe entre le temps de travail payé et le temps que va passer un développeur à écrire du code pour vous. Même si les délais sont différents. Car n’oubliez pas qu’une prestation est rarement chronométrée ; un plombier facture à l’heure mais n’a pas de chrono au tour du cou.

Le cahier de charges, quand il existe, donne l’impression que tous les points de réflexion sont déjà définis en amont et qu’il n’y a juste qu’à taper les lignes de code et hop ça marche. Mais franchement qui a déjà fait construire une maison dont les plans répondaient précisément à toutes les questions du chantier, dont les travaux se sont fait d’une traite, et dès la fin du chantier la maison était totalement terminée et habitable ?
Personne.

Cassons donc quelques mauvaises approches.

Le fantasme du script.

Non, tout besoin ne peut pas être résolu à coup de script. Le script, comprenez un code écrit (plus ou moins bien d’ailleurs) et exécuté tel quel, souvent étalé sur quelques fichiers de code, et exécuté en mode ça passe, tant mieux, ça bloque, tant pis, on réessaiera plus tard, encore et toujours, est trop souvent envisagé. Trop souvent validé, écrit, et trop souvent source de problème.

Il existe de très bons scripts. Il existe des solutions dans lesquelles c’est une bonne approche. Il y a même de grosses applications écrites qu’avec des scripts. Mais avez-vous le recul pour savoir si c’est la bonne approche ? Et je parle aussi des commerciaux qui vendent du temps de développement, et qui trouvent que ce genre d’approche est la meilleure car la moins cher pour leur client.

Parce qu’au pire, qu’est-ce que l’on risque, à part avoir payé un développement qui est source de problèmes plutôt qu’agir vers la solution pour plus en avoir ?

Et vous savez quoi ? Il n’y a fondamentalement pas de différence technologique entre un script une vraie application. Au final, le processeur l’exécutera avec les mêmes circuits. La seule différence notable étant l’approche du travail du développeur qui n’est pas la même. Et de fait, son temps passé n’est pas le même.

« Je veux juste »

C’est par cette phrase que commence un cahier des charges vocal. L’expression d’un besoin par quelques phrases. Ou plutôt l’aveu que l’on est dans le caca et que l’on a besoin d’un (gros) coup de main pour pas (trop) cher.

Je veux juste un tunnel qui relie ma cave au parking de mon bureau à 50 km. Je veux juste un avion qui relie Paris à New York en 30 min. Qui trouverais ces demandes normales (à part Elton Musk) ? Personne, vu que l’on peut facilement estimer l’énorme difficulté de ce genre de projet. Alors pourquoi le demander quand vous estimez que votre besoin est « juste un petit quelque chose » ? Et bien vous le ne savez pas. Car il est très difficile d’estimer la quantité de travail pour un projet de développement, et un besoin simple ne correspond pas forcément à un résultat simple.

Et c’est là où le professionnalisme de votre partenaire entre en jeu. L’expertise ce celui qui va se charger d’écrire le code compte, car c’est lui qui va déterminer si vous demandez la lune ou pas. Et vous le chiffrer correctement. Enfin, si vous voulez vraiment la Lune, faites une demande à Margaret Hamilton, elle a déjà fait.

Les retards

Un projet, ça a des retards. L’écriture de code, bien qu’il existe tout un tas de méthodes qui laissent penser le contraire, reste dépendante des aléas humains, et ne se sera jamais vraiment industrielle.

Expliquer un retard est difficile. Mauvaise évaluation dès le départ ou problème improbable en cours de route n’est pas facile à déterminer quand l’un dépend de l’autre. N’oubliez pas qu’écrire du code, c’est une forme de création. Qui voudrait imposer à un artiste un délai trop serré ?!

La toute puissance

Bon, quand on écrit du code, on a comme un délire de toute puissance qui germe en soit. Imaginez-vous entrer des instructions pour contrôler avec le plus d’exactitude possible une machine qui ne sais rien faire d’elle même. Et quand c’est ce code qui anime un robot ou vos désirs d’achats sur le web, cette puissance devient réelle.

Ce n’est donc pas si étonnant que les développeurs soient parfois des « gens spéciaux ». Voir un peu autiste sur les bords. N’en tenez pas compte si au détour d’une réunion vous trouvez louche le type qui va écrire votre code. C’est peut-être même bon signe !

Tout savoir faire

Comme dans plein de métiers, il y a des spécialisations. Un développeur est souvent spécialisé dans un domaine. Ne demander pas à un expert PHP dans une boîte de Com’ d’écrire un driver de carte graphique chez Nvidia. Et un développeur est plus ou moins à l’aise suivant le langage qu’il utilise – un violoniste saura se débrouiller avec une contrebasse, mais ne sera pas comme ça un virtuose. Même si le solfège est le même pour les deux instruments.

Embaucher, c’est dur

Et de fait, trouver le bon profil par rapport aux besoins n’est pas facile. Le recrutement de profil technique n’est déjà pas forcément simple, l’équilibre compétences/personnalité/salaire/opportunités que peut offrir l’employeur est difficile à trouver, encore plus quand votre concurrent direct outre-Atlantique débauche vos meilleurs profils pour le même type de poste au double du salaire.

La capacité, pour une boîte de développement, de recruter et de manager ses développeurs est ce qui la définira le mieux. Vous, en tant que client, vous le payerez si la boîte se trompe. La différence avec d’autres types de sous-traitante c’est que vous ne saurez pas quand ni combien vous le paierez…

Bien qu’au final vous voulez une application ou un site, vous vous rendrez compte que le facteur humain est crucial et que les problèmes techniques qui seront rencontrés seront sûrement des problèmes humains.

Choix technique

« Tout le monde utilise X avec Y, même Z, c’est dire que c’est la bonne solution » Remplacez X par une appli à la mode, Y par un framework cool, et Z par une grosse entreprise de la Silicon Valley, et vous avez l’équation de l’échec d’un projet de développement.

Alors calculons une autre approche : si X est à la mode, c’est peut-être qu’il est récent, qu’il manque de maturité, que la version actuelle risque d’être vite obsolète, et qu’il n’est peut-être pas adapté à votre besoin. Y est cool, mais peut-être qu’il existe quelque chose de mieux, plus moderne, plus souple, plus rapide, bref, qu’il est peut-être plus adapté à votre besoin ? Z l’utilise ? Ils peuvent ! Ils ont les équipes, les moyens et assez de méthodes et de métier pour savoir-faire, dans X ou Y, les corrections qui s’impose. D’ailleurs, le temps que vous opteriez votre application, Z aura eu le temps d’en écrire 3 fois plus que vous. Et chez eux ça marchera.

Le nucléaire, c’est puissant. On est tous d’accord. Areva, c’est une grosse boîte. Areva utilise du nucléaire. Ok. Une grosse boite qui utilise une méthode puissante ? Et non, vous n’aurez pas de réacteur nucléaire dans votre jardin. Et vous devrez vous en passer.

Bref, sachez estimez les propositions de technologie que l’on vous fait.

Mise en prod

Le grand moment est venu : la mise en production. Le moment où l’on démarre l’application pour de vrai, le moment ou le site est en ligne pour tout le monde. De ce que l’on en sait, ça marche chez les développeurs. Vous l’avez même vu marché récemment. Tout le monde y croit. En fait on n’a pas trop le choix : on a accumulé du retard, certains en font même des crises de rage. Le temps, c’est de l’argent, mais on va éviter de calculer le temps réel que ça a pris, notamment de votre temps de travail à vous. On est mardi, parce que les administrateurs système sont superstitieux. Ah, vous n’avez pas ça chez vous ? Bon alors on est vendredi soir et demain vous partez enfin au ski.

Et ça ne marche pas.

« Zut, un fichier vidéo, ça peut durer plus d’une heure » prends conscience l’un des développeurs, 3 jours après la tentative ratée de mise en prod chez son client, chez vous donc, après que de vilains messages d’erreurs marqués « Net Assembly truc » se soient joyeusement affichés sur votre écran, à peut prêt 59 minutes après avoir lancé un rec sur la belle appli toute neuve qu’avez demandé il y a de ça déjà 6 mois.

Un code qui fonctionne quelque part ne signifie pas forcément qu’il fonctionnera chez vous. Le développeur peut, à un moment donné ne pas prendre en compte un paramètre, même anodin, qui fait que sur son poste, ça marche et pas chez vous. Il existe beaucoup de méthodes et de technologies pour gérer une mise en production. Elles sont parfois lourdes à mettre en place, notamment en dehors des projets web pur.

Le plus complexe étant pour les robots ou l’utilisation de périphériques spéciaux comme une grille vidéo ou une carte d’acquisition haut de gamme : les équipes de développement n’en n’ont pas forcément une chez eux pour tester et donc… les tests se feront sur place, chez le client. Et dans votre intérêt, c’est mieux que ces tests soient faits avant la mise en production !

Bref la mise en production d’un code de quoi que ce soit doit être préparé, planifié, et vous devez vous investir totalement.

Et soyons clair : ça ne rigole plus, vous devez tout vérifier, que tout ce que vous avez demandé fonctionne, que les promesses soient bien là, et vous devez réclamer les raisons si ce n’est pas le cas. Bosser avec des bugs, c’est dur. Autant les faire corriger dès les départ.

Et ne vous laissez pas manipuler par les devs ! Qui ont tout intérêt à minimiser le moindre bug. Bas oui, c’est du boulot en plus !

Car si pour eux une mise en prod les rapproche de la fin du projet, pour vous c’est là où tout commence : la difficulté va maintenant être de réclamer la reconnaissance et la correction des bugs. Si ça ne fonctionne pas chez vous mais chez eux ça marche… alors ils vont devoir d’abord arriver à reproduire le bug chez eux pour pouvoir le corriger ensuite. Et d’ajouter des fonctions manquantes.

Il faudra se mettre d’accord sur ceux que l’on va corriger ou faire, et ceux que l’on va laisser de coter.

Sachez aussi qu’un bug est toujours corrigible (sauf cas très rare) mais ce n’est pas forcément facile (ou même difficile). En fait, en tant qu’utilisateur, il est impossible d’estimer le travail nécessaire à la correction d’un bug. Oui, un bouton mal aligné peut-être le résultat d’un problème pas du tout évident. De même qu’un « / » manquant peut l’être la cause d’un crash. Pour le savoir, il faut fouiller dans le code, comprendre ce qu’il est fait, et pourquoi le résultat attendu n’est pas là. C’est à ce moment là où la qualité du code rendre en jeu : un code clair, organisé et documenté sera beaucoup plus simple à modifier. Un code crade, pour le modifier, il faut parfois supprimer et réécrire des morceaux entiers. La dépense en début du projet devient une économie à la fin, en quelque sorte.

Puis une nouvelle version arrive. Cette nouvelle version est sensée corriger comme prévu des bugs. Et votre travail va être… de tout re-tester ! Car qui vous dit que la correction des bugs et l’ajout de nouvelles fonctions ne va pas ajouter des régressions ? C’est à dire de nouveaux bugs a des endroits qui fonctionnaient bien avant. Je vous n’avais pas dit qu’une mise en production demandait un réel investissement de votre part ?!

Et ainsi va le cycle de développement : retour/demande client -> remonté de bugs et de nouvelles fonctions -> prise en charge développeur -> contrôle qualité interne -> livraison client… jusqu’à la fin du projet !

En conclusion : vous savez quoi ? J’ai vu passer toutes ces erreurs. Oh, rien de catastrophique, je vous rassure, et dans la plupart des cas je n’avais pas vraiment le choix, alors faites attention et renseignez-vous, documentez vous, bref, apprenez !

La suite, ou vous aurez quelques termes techniques à savoir pour briller en réunion.