LinkiDev en toute transparence

Je suis Alexandre Cane, fondateur de LinkiDev. De 2011 à 2016, j'ai dirigé ma propre entreprise — gestion d'équipe, marges, clients, fournisseurs, trésorerie : le quotidien d'un patron de PME. En 2017, j'ai basculé vers le développement et lancé LinkiDev. Depuis 2019, je suis également responsable informatique en CDI dans une PME, et je porte LinkiDev en parallèle. Sur vos projets, c'est cette double casquette qui parle : le dev qui code, et celui qui a vécu vos contraintes de dirigeant de l'intérieur.

Oui, et je l'assume. Avoir un revenu principal stable signifie que je n'ai pas besoin de signer chaque mission qui se présente : je choisis mes clients, je peux refuser une demande qui ne sert pas leur intérêt, et je n'ai pas la pression de remplir un agenda à tout prix. En contrepartie, je suis transparent sur ma capacité — je dégage du temps pour LinkiDev en dehors de mes heures de salarié, et je sais m'organiser pour répondre présent quand un projet entre dans une phase plus dense. Si votre projet exige une mobilisation 100 % temps plein sur une semaine donnée, je vous le dirai dès le cadrage.

Deux grandes familles de missions. D'un côté, l'intégration d'APIs : avec des scripts pour faire dialoguer des outils qui ne se parlent pas, automatiser des flux entre votre CRM, votre facturation, votre ERP, vos outils métier. De l'autre, le développement d'applications web de gestion sur-mesure — outils internes pensés pour vos process spécifiques, là où Excel ou un SaaS ne suffisent plus.

Je travaille avec des technologies éprouvées et largement utilisées (PHP/Symfony, JavaScript, bases de données SQL), celles qu'on retrouve dans la majorité des entreprises. Concrètement : si demain vous deviez confier la maintenance à un autre prestataire, il trouverait sans difficulté quelqu'un qui connaît ces outils. L'hébergement peut se faire chez des acteurs français quand le sujet l'exige. Aucun choix exotique pour le plaisir : je privilégie ce qui sera encore lisible et maintenable dans cinq ans.

Trois points concrets :

1. chaque projet est livré avec sa documentation technique et fonctionnelle, lisible par n'importe quel développeur qui prendrait la suite,
2. le code vous appartient — sources, dépôt Git, accès,
3. j'utilise les conventions standard Symfony et PHP, sans framework maison ni pattern exotique : un autre développeur du même niveau peut reprendre la main sans archéologie.

Oui, c'est un vrai risque, et je préfère le nommer plutôt que l'enrober. Je le borne de plusieurs façons :

• un travail livré propre et documenté, conçu dès le départ pour qu'un autre prestataire puisse en prendre la suite sans repartir de zéro,
• un réseau de développeurs de confiance vers qui réorienter en cas d'indisponibilité prolongée,
• une relation de fidélité avec mes clients : la plupart sont là depuis plusieurs années. Je connais leurs systèmes, ils savent comment je travaille — la continuité, c'est aussi ça.

Les urgences sont traitées en réactivité best-effort dans les 24 à 48h. Pour les sujets critiques (production en panne, blocage majeur), je sais être réactif. Pour les évolutions et le confort, on planifie sur des créneaux dédiés. C'est un compromis honnête : vous n'avez pas un dev en astreinte 24/7, mais vous avez quelqu'un qui répond et qui connaît votre système.

Les agences comme les freelances ont chacun leurs forces, et selon votre projet l'un ou l'autre sera parfois le bon choix. Ce que j'apporte de spécifique, c'est une double lecture héritée de mon parcours de dirigeant (cf. plus haut). Je sais ce qu'est une fin de mois tendue, un client qui pousse, une équipe à embarquer, une décision à prendre vite. Quand vous me parlez d'un besoin, je l'entends comme un dirigeant — pas seulement comme un technicien.

Ça change la phase de cadrage. Je ne vais pas vous coder ce que vous demandez si je sens que ce n'est pas ce qui résoudra le problème métier sous-jacent. Je vais vous poser des questions sur vos process, votre équipe, vos contraintes de marge ou de délai. Parfois la meilleure solution est un script de 200 lignes au lieu d'une application complète. Parfois c'est l'inverse. L'expérience business sert exactement à ce moment-là : éviter de surdimensionner, ou de sous-dimensionner.

Les deux, selon ce qui vous arrange. Le forfait quand le périmètre est clair et stable : vous avez une visibilité budgétaire totale, je porte le risque de dépassement. La régie quand le besoin va évoluer en avançant, ou pour de la maintenance et des évolutions ponctuelles : facturation au temps réellement passé, suivi détaillé. On choisit ensemble au cadrage, et rien ne nous empêche de basculer d'un mode à l'autre selon les phases.

Vous n'êtes pas obligés de rester. Le code vous appartient, la documentation aussi, vous pouvez reprendre la main ou confier à un autre prestataire à tout moment. Pour être franc sur le volume : je travaille avec 3 clients fidèles — deux depuis 9 ans, un depuis 4 ans. Je ne cherche pas à empiler les missions, je cherche la durée. Connaître un système sur plusieurs années fait gagner un temps considérable sur chaque évolution — c'est ce modèle que je privilégie : peu de clients, longtemps.