Questions à poser à un développeur web avant de recruter
La plupart des questions posées lors d'un premier échange portent sur la technologie, et la technologie est ce qui compte le moins pour la réussite du projet. Les questions qui prédisent le résultat portent sur le processus, la propriété et ce qui se passe quand quelque chose tourne mal.
Ce guide liste ces questions, regroupées par ce qu'elles révèlent, avec une note sur ce à quoi ressemble une bonne réponse.
Sur le travail lui-même#
Elles établissent s'ils ont compris votre projet ou s'ils décrivent leur offre standard.
| Question | Écoutez |
|---|---|
| Quelles questions avez-vous sur notre activité ? | N'importe lesquelles. Le silence ici est le signal négatif le plus fort qui soit |
| Montrez-moi un site en production à notre échelle | Une URL, pas une image ; idéalement pas leur vitrine |
| Que feriez-vous différemment de notre site actuel ? | Des observations précises, signe qu'ils ont regardé |
| Quelle est la partie la plus risquée de ce projet ? | Une réponse honnête : généralement le contenu ou les intégrations |
| Qu'est-ce qui n'est pas inclus dans ce devis ? | Une liste précise donnée volontiers |
| Combien de temps, et qu'est-ce qui le détermine ? | Un calendrier avec des dépendances, pas un chiffre isolé |
Sur le processus#
Elles séparent ceux qui ont une façon de travailler reproductible de ceux qui improvisent.
- Où le code est-il stocké, et y aurons-nous accès dès le premier jour ?
- Comment un changement passe-t-il de votre machine au site en production ?
- Où relisons-nous le travail avant sa mise en ligne ?
- À quelle fréquence verrons-nous les avancées, et sous quelle forme ?
- Qui exactement fera le travail, et que se passe-t-il si cette personne est indisponible ?
- Comment testez-vous : navigateurs, appareils, accessibilité, performance ?
- De quoi avez-vous besoin de notre part, et pour quand ?
La question du déploiement est la plus révélatrice de toutes. Une réponse impliquant de glisser des fichiers dans un client FTP vous dit qu'il n'y a ni gestion de versions, ni préproduction, ni retour arrière.
Sur ce qui se passe ensuite#
La période sur laquelle personne n'interroge pendant la présentation et qui préoccupe tout le monde six mois plus tard.
- À qui appartiennent le code, le domaine et les comptes d'hébergement après le lancement ?
- Quel support est inclus après le lancement, pendant combien de temps, et qu'est-ce qui compte comme défaut ?
- Combien coûte ensuite un petit changement, et quel est le délai ?
- Proposez-vous de la maintenance, que contient-elle, et recevons-nous un rapport ?
- Si nous cessons de travailler ensemble, que recevons-nous et sous quel délai ?
- Un autre prestataire peut-il reprendre ? Quelle documentation existe ?
- De quels services tiers le site dépendra-t-il, et qui les paie ?
Des réponses qui devraient mettre fin à la conversation#
Rares, mais bonnes à reconnaître immédiatement.
| Réponse | Pourquoi cela disqualifie |
|---|---|
| « Nous garantissons des positions en première page » | Personne ne le peut ; c'est de l'ignorance ou de la malhonnêteté |
| « Nous gardons le domaine sur notre compte » | Cela fait de vous un otage |
| « Vous n'avez pas besoin de préproduction, nous faisons attention » | Tout le monde fait attention ; ce n'est pas un processus |
| « Sur les petits sites nous n'utilisons pas de gestion de versions » | Pas d'historique, pas de retour arrière, pas de second prestataire |
| « Le prix n'est valable que si vous signez aujourd'hui » | Les tactiques de pression prédisent la relation de travail |
| « Le SEO est inclus », sans détail | Soit cela ne veut rien dire, soit une prestation distincte est sous-entendue |
| « On verra les détails au fur et à mesure » | Avec un prix ferme, cela devient votre problème |
Questions fréquentes
Quelle est la question la plus utile ?
« Comment un changement passe-t-il de votre machine au site en production ? » Toute personne compétente y répond en une phrase, et la réponse révèle si gestion de versions, préproduction, relecture et retour arrière existent. Tout le reste de la liste sur le processus en découle généralement dans un sens ou dans l'autre.
Dois-je poser des questions sur des technologies précises ?
Seulement là où vous avez une vraie contrainte : un système existant, une plateforme que votre équipe utilise déjà. Sinon la technologie est leur décision, et poser la question invite une réponse conçue pour impressionner. Demandez plutôt les résultats produits : quelle vitesse, quelle maintenabilité, qui d'autre pourrait travailler dessus.
Comment vérifier correctement une référence ?
Interrogez sur un problème plutôt que sur la satisfaction : « qu'est-ce qui a mal tourné, et comment ont-ils géré ? » Tout projet a quelque chose. Une référence incapable de citer quoi que ce soit a soit eu un projet trivial, soit n'est pas tout à fait franche. Demandez aussi si elle les reprendrait pour un projet plus important, question plus tranchante que celle de la satisfaction.
Est-il malvenu de poser des questions sur la propriété et la résiliation ?
Non, et un fournisseur professionnel s'y attend. Les deux parties gagnent à savoir où elles en sont, et les réponses sont courtes. Une gêne face à ces questions est en soi une information : cela signifie généralement que l'arrangement standard vous est moins favorable qu'il ne devrait.
questions développeur webrecruter un développeurentretien développeur webquestions projet webchoisir un développeurévaluer un développeur
