Lors d’un échange récent, dans la foulée d’une inflation manifestement mondiale, un de nos très anciens clients belges m’a indique que nos prix de développement web nearshore en Roumanie étaient arrivés au niveau de celui de la Belgique. Ce à quoi je lui ai répondu que j’étais à la fois d’accord… et pas d’accord! Tout dépend en effet à quoi on compare les prestations de notre agence de développement web offshore ; un freelance, une société de services informatique? Et cela dépend aussi beaucoup du mode de réalisation et de facturation de ce développement web near-shore… Entre régie dédiée, travaux aux forfait ou maintenance évolution facturée à l’heure, les différences sont considérables…
Comme le développement de sites et appli web se fait en Roumanie, on considérera que Transycons est une agence web nearshore… pour nos clients d’Europe de l’Ouest. Mais nous sommes en même temps une agence web offshore en cas de sous traitance de projet web de clients d’Amérique du Nord. Ce qui explique que j’emploie les termes de manière assez indifférenciée. Tout dépend de l’emplacement géographique de celui qui lit…
A vrai dire, les donneurs d’ordres en sous-traitance web attendent avant tout de la flexibilité, et l’un de ses aspects est représenté par les manières diverses – et évolutives – dont nous réalisons leur projets web offshorés.
Le plus souvent, on choisit au départ un type de développement web à distance (et de facturation) et on le conserve sur une longue durée. Mais il existe aussi des cas ou l’on change de mode de facturation en cours de route. Ou des cas ou, pour un même client, en fonction du type de taches, on utilisera l’un ou l’autre des types de facturation.
Développement offshore de sites web au forfait
Ce mode de fonctionnement est le plus courant;
En général, les clients qui recherchent une agence de développement offshore ou nearshore ont un budget très serré. Donc connaitre dès le départ prix du développement est pour eux un pré-requis.
Les choses se compliquent parfois du fait qu’un prix est associé à un résultat qui doit être spécifié de manière précise et détaillée. Dans certains cas le du besoin client est suffisamment clair quand on commence le développement. Ensuite les choses sont assez stables pendant le travail jusqu’à la finalisation de la V1.
Dans d’autres cas, c’est plus délicat. Le client ne peut s’empêcher de changer de multiples éléments en cours de projet. Il “améliore par itération” en fonction de ce qu’il voit sur le site en construction. Dans une telle configuration, on partira plutôt sur une logique de “clé en main”… (nous allons détailler plus loin)
Il existe aussi une variante pour les toutes petites bourses. Quand on nous indique que le budget est très serré, nous pouvons aussi avoir une logique de design to cost, c’est à dire d’indiquer au client ce qui “rentre” dans son budget.
Un cas de figure approchant concerne les petites agences qui confondent programmation nearshore et ultra low cost. Quand nous avons des signaux indiquant que le budget de développement doit être ultra limité, nous demandons maintenant au client quel est son budget. En effet les études de projets nous prennent du temps, donc ont un coût significatif. Plutôt que de nous consulter en interne pour trouver la meilleure solution technique, et préparer un devis détaillé, mieux vaut savoir d’entrée quelle est l’enveloppe disponible. Sachant qu’elle risque fort d’être insuffisante pour faire un travail sérieux, même en Roumanie.
Ce faisant, tout le monde, à commencer par le prospect, gagne du temps, même si les clients n’apprécient pas toujours cette démarche. Ils préféreraient partir d’une cotation qu’ils pourraient ensuite essayer de négocier à la baisse. Mais avec une telle logique ils ne sont pas dans notre cible. Nous avons un impératif de rentabilité.
D’ailleurs les clients qui tentent en bout de course, après la préparation des documents juridique, le briefing des interlocuteurs, etc, d’obtenir un très conséquent discount de dernière minute sur la base d’une offre d’un prestataire inconnu dans un improbable pays offshore en sont pour leur frais. Tout le monde aura perdu du temps pour rien…
Développement web offshore clé en main
Dans certains cas nous n’avons pas tous les détails concernant un projet. Ou nous supposons fortement que la demande pourra évoluer sensiblement en cours de développement.
Nous définissons cependant un budget approximatif, nous prévoyons en toute transparence une poire pour la soif, et si le client est d’accord et verse un acompte, nous nous mettons au travail.
Dans certains cas, les ajouts et suppressions se compensent à peu près, donc le budget initial pourra être respecté. On peut même ne pas consommer tout le budget prévu, mais c’est assez rare…
Si les choses ne se font pas “spontanément”, avant chaque nouveau sprint, quand le client rajoute des éléments non prévus au cahier des charges, il lui est proposé en contrepartie de repousser le développement d’autres éléments à une version ultérieure du site.
Enfin, dans le cas ou il y a beaucoup de nouveautés, quand l’essentiel du budget initial a été consommé, nous prévenons le client. Souvent nous basculons sur de la facturation à l’heure, sur la base de rapports de taches très détaillés.
Sur ce type de gros projets, l’important est de facturer régulièrement. Il faut aussi être transparent et précis sur le temps passé pour ce type de client.
Développement web en régie offshore mutualisée
Les SSII qui travaillent pour les PME savent que celles-ci ont rarement des besoins stables et durables. Surtout pour la maintenance évolution d’applications de sites ou application web existants. Au fil du temps, il est nécessaire de recourir ponctuellement à différents profils de développeurs ou graphistes web, pour traiter au fil de l’eau les demandes.
Le recours à un Chef de Projet coté agence web offshore est nécessaire pour gérer et prioriser la charge de travail entre les principaux clients. C’est ce CP qui affectera la première personne disponible pour traiter les nouvelles demandes.
Bien évidemment, même en additionnant les clients qui se compensent en partie, la charge de travail globale n’est pas constante. Il y a donc des périodes ou une partie des développeurs n’est pas occupée. A l’inverse, il u a des pointes pendant lesquelles les délais s’allongent un peu du fait du grand nombre de taches à traiter simultanément.
Quand les délais s’allongent, il faut faire un travail de pédagogie pour expliquer la situation aux clients. Les programmeurs offshore ne leur sont pas dédiés, mais ne leur sont pas non plus facturés en totalité, ce qui implique d’être compréhensif…
Dernier point, la facturation du travail se fait sur la base de l’envoi périodique de rapports détaillés sur le travail réalisé. En général le rapport mentionne la date du mail de demande, ou le numéro de ticket. Cela permet à la fois aux clients de refacturer facilement le travail quand c’est nécessaire. Et aussi d’afficher une transparence requise pour maintenir la confiance indispensable pour ce type de facturation. En effet le client doit être assuré que les temps de travail facturé pour la maintenance évolution offshore est sincère, et non exagéré.
Equipe de développement web dédiée
Développement web full Offshore
Mettre en place une équipe de développeurs offshore dédiée peut souvent se révéler un défi. Il faut réussir une alchimie particulière entre l’équipe et le chef de projet client. Pour cela, une visite du client sur le site offshore, idéalement lors du démarrage d’activité, est précieuse. Des gens qui se connaissent car ils se sont vus « en vrai », voire ont passé quelques moments agréables ensemble seront beaucoup moins dans la confrontation en cas de différent. L’empathie sera bien plus forte, ainsi que désir de trouver, ensemble, des solutions.
Il faut aussi que la partie client concentre au maximum les demandes sur l’un de ses membres. Ou mette en place une coordination pour s’assurer de la cohérence des demandes. Du coté prestataire offshore aussi, il faut prévoir un peu de gestion de projet web pour s’assurer que tout se passe bien et éviter d’éventuelles frustrations. Par exemple lors d’un syndrome « centre / périphérie » ; le centre (côté client) considère que toutes ses demandes sont prioritaires, mais néglige de répondre aux questions des exécutants du site de développement (périphérie) qui ne peuvent avancer faute de réponses…
Enfin, il est recommandé de démarrer l’activité progressivement, par exemple avec deux développeurs et un chef de projet à temps partiel. Après une phase de test, qui permet de bien cadrer l’activité sous traitée, l’équipe offshore peut se développer progressivement. ceci d’autant plus que les process de formation se sont rodés avec l’expérience. Si une personne ne se plaît pas ou ne fait pas l’affaire, elle est assez facile à remplacer. en effet, l’équipe a déjà acquis une vitesse de croisière et une connaissance fine des attente du client.
Développement web Inshore
Il existe aussi des cas ou les salariés issus des pays de développement offshore sont appelés à travailler dans le pays du client final. Au moins le chef de projet.
Nous recevons parfois des demandes de ce type. Ce système étant très usité en Allemagne par exemple. Au moins pour un détachement pendant 2-3 jours par semaine.
Mais il faut savoir que le marché du développement web a changé dans les pays offshore/nearshore. Comme les salaires et le niveau de vie ont sensiblement augmenté dans ces pays offshoreurs, l’écart avec les pays occidentaux s’est réduit. Il peut même être négatif si on tient compte des différence de coût de la vie. Un développeur roumain qui certes gagne un peu moins chez lui aura un meilleur niveau de vie au pays. Surtout si il est propriétaire, et qu’il évite de partir faire des missions dans des pays ou la vie est très chère.
De plus, les personnes recherchées sont des ingénieurs avec une réelle expérience, donc souvent ils sont déjà en couple « stable », voire ont des enfants. Ceci qui limite très fortement leur mobilité.
Enfin, le télétravail a fait sa place dans les têtes. Les développeurs ont constaté qu’il était applicable. Ils sont donc logiquement plus réticents à la « mobilité lointaine » qu’avant.
Bref le développement web en in-shore n’est pas simple à mettre en place. On peut envisager un déplacement d’assez courte durée au début, pour que la mission se mettre bien en place. Puis le détaché retourne chez lui pour poursuivre en télétravail. Sinon on peut aussi tabler sur des courts séjours périodiques de 2-3 jours dans les locaux du client.
Pour conclure, on peut signaler que plus que de l’endroit ou de la distance, avant d’externaliser ses développement web il faut se poser la question du type de structure offshore avec laquelle on pourrait travailler. Il faut étudier sa taille, qui doit être assez comparable à la sienne. On doit aussi analyser l’ancienneté du partenaire potentiel, sa pérennité, le contexte général des infrastructures et du pays, qui doivent être aussi stables et surs que possible.
Certains prestataires sont mono sites ou mono pays, d’autres sont multi-continent et réalisent à la fois du développement web offshore et nearshore (ou plutôt offrent des services informatiques nearshore à leurs clients, ou qu’ils soient).
Pour que le rapport qualité / coût /délais soit optimal, il est important que les donneurs d’ordre des projet informatiques outsourcés annoncent très tôt les nouvelles tendances observées sur le carnet de commande. Cette transparence est hélas trop rare…
La société de développement web offshore étant loin des yeux, elle est hélas aussi souvent “loin du cœur”. Prévenir par exemple d’une augmentation des ventes qui permettrait de lancer des embauches. Le prestataire aurait plus de temps pour monter en charge, et une augmentation des commandes ne se traduirait plus forcément par une extension des délais. A l’inverse, anticiper le désengagement des personnes permettrait par exemple de geler les embauches, d’éviter que certains développeurs offshore ne soient pas occupés, et donc de mieux maîtriser les coûts du service offshore.