En début d’année, nous avons démarré une collaboration étroite et prometteuse avec l’éditeur d’une application métier / logiciel destiné aux établissements d’enseignement supérieur de Roumanie. Le volume d’activité augmente très rapidement, signe que le client a trouvé ce qu’il recherchait.
Au départ ce client provient d’une connaissance personnelle d’un des associé de Transycons, dans un cadre « associatif ». Au bout de quelques années, ils en sont venus à échanger sur leur activité pro, et ont découvert qu’il y avait des recouvrements, notamment au niveau des technologies (PHP et consorts). Comme avec le temps un bon niveau de sympathie et de confiance s’était mis en place, il a été facile d’embrayer sur une collaboration concrète.
Changer de modèle de développement de l’application métier
Notre interlocuteur était le concepteur, animateur et propriétaire d’une application logicielle permettant aux universités et établissement supérieurs de gérer de nombreux aspects administratifs de la scolarité des élèves. Depuis 2008, le propriétaire avait fait appel à divers freelance pour développer et faire grandir l’application, tandis que lui se chargeait de la partie commerciale, gestion de projet et gestion de l’entreprise.
Mais il était parvenu à un point ou la fragmentation des ressources et des interlocuteurs, leur instabilité aussi, devenaient trop pénalisante.
Il a donc décidé de passer progressivement à un nouveau modèle, en faisant appel à Transycons, pour disposer, au sein d’une structure unique, de ressources bien supérieures à celle d’un freelance. Un tel changement a aussi permis de beaucoup mieux capitaliser l’information technique, et au-delà.
Comprendre l’activité de l’éditeur d’application
La première étape a consisté à comprendre l’activité du client.
Ce n’est pas une nouveauté car développant du sur mesure, nous sommes largement des « multi-spécialistes ». Apprendre et et comprendre fait partie de notre ADN. Le secteur de l’enseignement supérieur a des besoins et modes de fonctionnement bien spécifiques, qu’il nous a fallu intégrer.
Très sommairement, la donnée de base est que les règles changent régulièrement (tant au niveau national que de l’UE) ce qui continue un levier pour faire évoluer l’application, et un moteur commercial pour vendre les travaux d’évolution de l’application. Ces changements sont aussi pour nous des pourvoyeurs réguliers d’activité.
Comprendre les grandes lignes de l’activité à nécessité une série d’entretiens entre le fondateur-animateur de l’application métier et notre responsable technique, qui joué également le rôle de chef de projet vis a vis du client.
Passée la phase commerciale, ces temps ont aussi été intégrés aux rapport d’assistance.
Il s’est agi d’un investissement en temps que les deux parties ont réalisé, mais que sera facilement amorti à moyen terme.
Comprendre la logique et le fonctionnement de l’application
En parallèle il a fallu rentrer dans l’application pour comprendre son architecture et son fonctionnement. Notre interlocuteur, chef d’entreprise, n’a guère pu nous aider, n’étant pas lui même techniciens. Le code n’était souvent pas commenté, ou pas de manière explicite pour une autre personne que celle qui a laissé les notes.
Certains éléments avaient été réalisés à la fin des années 2000, par des personnes dont la trace avait été perdue.
Il a donc fallu mener un patient travail d’enquête pour s’orienter.
Nous avons beaucoup été aidés par la polyvalence et l’expérience de nos équipes qui pour diverses raisons ont eu à reprendre des applications PHP souvent complexes sans recevoir d’indications techniques quand cela aurait été souhaitable.
Nos développeurs full-stack ont largement découvert par eux même en traitant les premières demandes de maintenance.
Puis nous avons commencé a rendre l’application moins statique et plus paramétrable.
Nous avons aussi travaillé à identifier les causes des problèmes les plus fréquents pour les résoudre en priorité.
La gestion des serveurs
Ce domaine est particulièrement sensible.
En effet il est était par un freelance auquel il assure depuis des années un revenu régulier.
Et qui était particulièrement jaloux des informations dont il disposait (ce qui est aussi compréhensible pour un admin serveur 😉 )
L’effet « boite noire » du système était de plus renforcé par le fait qu’un seul serveur était utilisé, car celui ci comportait en son sein un grand nombre de machines virtuelles, très difficiles à identifier et impossible à comprendre en détail de l’extérieur.
La demande de clients voulant être rassurés sur cette partie a heureusement permis d’avoir des information en vue d’augmenter progressivement la résilience de l’application.
Et l’apprentissage continue régulièrement sur cette partie vitale.
Inciter l’éditeur du programme à s’organiser
Notre interlocuteur n’a jamais vraiment eu l’occasion d’avoir une vision et une approche globale.
Il était un chef d’orchestre interagissant avec divers freelance bien plus qu’un compositeur qui réfléchit et conçoit l’ensemble d’une symphonie.
Il avait pris l’habitude de lancer le développement de nouveaux modules en se contentant d’indiquer les grandes lignes, puis de compléter, en se posant des questions une fois qu’on l’interrogeait sur tel ou tel aspect non détaillé dès le départ.
Or cette habitude n’est pas optimale. Déjà du point de vue de l’architecture, l’architecte du module n’ayant pas forcément une vue d’ensemble du besoin. Moins encore en terme de respect des délais et d’allocation des ressources, car cela rend la planification à long terme largement inopérante.
Nous incitons donc le chef de projet à nous donner un maximum d’infos dés le départ, pour parvenir à mieux caler les projets.
L’enjeu n’est pas seulement financier, d’autant que le client comprend bien que son approche rajoute des travaux non prévus qu’il faut bien payer. Mais, spécialement pour les « gros » modules, revenir au final en arrière pour modifier ou ajouter des éléments n’est pas optimal, on passe sensiblement plus de temps que si tout avait été planifié dès le départ…
Enfin, le fait d’avoir pendant une assez longue période des modules « presque terminés » qui peinent à aboutir en attente d’une validation finale a aussi un impact sur la facturation, donc sur les encaissements et les flux de trésorerie…
Construire la confiance
Sur des projets de maintenance d’appli web, la confiance est encore plus vitale que pour d’autres types de projets, par exemple des développements ponctuels au forfait.
En particulier pour la facturation des petites taches de maintenance, qui ne peuvent toutes faire l’objet de cotations. En effet cela alourdirait trop les échanges et ralentirait le démarrage des interventions. En contrepartie, le prestataire qui assure la maintenance doit proposer des rapports les plus précis et détaillés possibles. Ils doivent être disponibles à tout moment, en ligne, et les membre de l’équipe doivent les tenir très régulièrement à jour.
Plus globalement, lors des premières semaines ou même mois d’une telle collaboration, notre chef de projet a passé beaucoup de temps à échanger avec client pour comprendre ces besoins. Il lui a au passage proposé diverses suggestions. Ce temps a une valeur, et doit être apprécié sur l’ensemble de la collaboration.
En définitive, la facturation de notre travail est basé sur un hybride entre forfait et régie facturée au temps passé. Ce qui est très fractionné est facturé au temps passé, et les principaux modules font l’objet de devis qui sont le cas échéant (souvent) complétés en fonction des suppléments fonctionnels qui apparaissent en cours de route, surtout une fois que l’essentiel du développement initial a été réalisé.
Bref, les deux partenaires doivent parvenir à former une symbiose durable… sans que l’une des parties, spécialement le prestataire informatique sous traitant la maintenance évolution, n’abuse de sa position et de sa connaissance privilégiée des besoin de son partenaire.
Une telle symbiose peut aussi permettre d’optimiser les délais et les volumes de travail. Si par exemple le client sait qu’il a un besoin, même si il ne pourra le facturer que dans quelques mois, et si le prestataire fait face à un besoin d’activité, les deux partenaires peuvent se mettre d’‘accord pour lancer le développement d’un module sur la base d’un acompte plus faible qu’en temps normal. Sachant que les flux de trésorerie se régulariseront au bout de quelques mois…
Pour conclure, il faut être lucide sur le fait que reprendre la maintenance évolution d’une application métier sur mesure ancienne demande un fort investissement des deux parties.
Tous les développeurs ne veulent pas faire ce travail de maintenance évolution, souvent sur des technologies plus anciennes. Heureusement, nous disposons de profils adaptés. Ils ont aussi une forte capacité à rentrer dans des applis, souvent peu documentées, pour en comprendre progressivement les tenants et aboutissants. Taches pour l’instant difficilement remplaçables par l’IA…
Bien sur, d’autres profils se régalement à développer de nouveaux modules, qui représentent un autre versant de la nouvelle activité.
Nos clients bénéficient à plein de nos compétences globales, car outre le développement back-end, nous avons aussi la capacité à restyler, voire redesigner les front-end anciens et austères…
Enfin, last but nos least, existant depuis 2002, nous apportons une stabilité bienvenue aux clients à une époque ou les bouleversements s’enchaînent…