Votre PME grandit, mais les fichiers Excel circulent encore par e-mail ? Les informations se perdent avec le télétravail ? Vos services peinent à collaborer ?

Il est temps de structurer vos processus et d’adopter une solution applicative adaptée. Mais comment choisir ?

Se fier au prix, à la réputation, ou à ce qu’utilise un concurrent ? Construire son propre outil ? Et qui pour le développer : une agence, une équipe en interne ? Qui les pilotera ?

Autant de questions sans réponse universelle. Tout dépend de votre contexte, de vos besoins et de votre marché.

Pour faire le bon choix, voici les étapes essentielles à suivre.

‍

1. Une structure d’équipe adaptée à votre solution applicative

1.1. Définir vos besoins

Comment définir vos besoins ? Qui est le mieux placé pour comprendre ce qui pourrait vous aider à créer de la valeur dans vos processus ?Deux solutions existent :

Solution 1 : Nommer une personne en interne.Cela peut paraître une bonne idée. Elle connaît les processus métier et ne vous coûte pas plus cher, mais vous en aurez pour votre argent. Dans le meilleur des cas, cette personne dressera une liste plutôt que de proposer des solutions. Car oui, embaucher des personnes en plus ou mettre en place un fichier Excel contenant des macros développées en Visual Basic grâce à ChatGPT ne sont pas des solutions.

Mais c'est normal : en quoi cette personne est-elle qualifiée pour recueillir les besoins métier, prendre du recul sur l'existant et rassembler les différents besoins de l'ensemble des services qui composent votre société ? Par exemple, le service communication et le service commercial ont tous deux besoin de stocker les contacts. Le premier pour envoyer des campagnes marketing, le second pour l'animation commerciale.

Les informations nécessaires, les processus de mise à jour et les outils peuvent donc être très différents.

Une personne en interne pourrait ne pas identifier ces nuances, car elle est trop proche des opérations quotidiennes et manque de perspective globale. Elle pourrait ne pas voir comment les besoins spécifiques de chaque service peuvent être harmonisés ou optimisés à l'échelle de l'entreprise.

Solution 2 : Faire appel à une ressource externe.Si vous n'avez pas la ressource interne pour centraliser les différents processus afin d'avoir une vision globale de votre entreprise, ou si vous avez testé la solution précédente, le mieux est de faire appel à une ressource externe.

Une ressource externe, mais qui ? Et comment ? Si vous pensez de recruter un développeur : aussi compétent soit-il, vous n'arriverez pas à communiquer avec lui. Vous allez décrocher au moment où il vous dira qu'il a besoin « d'une instance AWS orchestrée sur K8S pour déployer la fonctionnalité avec la CI ». Nous apportons les solutions concrètes et adaptées a votre besoins dans la suite de l’article.

1.2. Le rôle de votre équipe projet et métier dans la construction de votre solution applicative

Le développement d’une application est un art qui nécessite plusieurs corps de métier.

Vous entendrez souvent vos collaborateurs dire « mais je ne suis pas informaticien », mais pour autant, ils sont une mine d'or. Ils sont capables de dérouler tous les processus; il est absolument nécessaire de les embarquer dans le projet dès le début. Le but est d'éviter la boîte noire : d'un côté, pour que le métier puisse suivre et valider les différentes étapes, et de l'autre, pour que l'équipe qui réalisera le projet puisse ajuster les demandes de manière à rester sur les rails et livrer les fonctionnalités nécessaires.

On parle ici de méthode « Agile », qui consiste à réaliser les développements par petites itérations en impliquant l'ensemble des personnes concernées. Fuyez la méthode en V, qui, par définition, silote les missions de chacun. Chacun se renvoie la patate chaude sans communiquer, et le délais entre le début du projet et la livraison est tellement long que le produit livré ne correspondra plus à vos attentes.

Il n’y a pas de recette miracle dans la réalisation d’un projet informatique, et pour corser la chose, il est très difficile de prédire et d’estimer le temps nécessaire pour le réaliser.

C’est un peu comme la maçonnerie : quand votre maçon vous dit que vous serez livré de votre superbe nouvelle maison dans un an, vous savez que ce n’est pas vrai. Il y a des impondérables qui arrivent en cours de route, comme le mauvais temps, les retards de fournisseurs, les arrêts maladie, etc. Et bien, c’est pareil en informatique, à la différence que votre maison, vous la voyez se construire et vous pouvez vous projeter facilement, alors que du code informatique ne vous parlera pas. Pour répondre à ce problème, il faut vous entourer de personnes de confiance qui peuvent vous alerter ou vous rassurer, car c’est leur métier.

1.3. Construire une équipe efficace

Dans un premier temps, voyons l'équipe minimale, le socle qui permet de démarrer une application.

Un chef de produit, souvent connu sous le nom de « Product Manager », aura pour rôle de collecter et de valider les besoins auprès de vos collaborateurs, de rédiger les différentes documentations fonctionnelles, de prioriser les fonctionnalités clés apportant de la valeur, et de tester l'application. D'ailleurs, arrêtons-nous sur les tests. Vos collaborateurs s'attendent, lorsque le projet est livré, à ce que cela fonctionne, et testent au minimum les processus les plus standard. C'est de la responsabilité du chef de projet d'écrire l'ensemble des scénarios possibles, de les tester et de valider que les fonctionnalités livrées ont le comportement attendu.

Un UI/UX designer : vous verrez que vos collaborateurs ont beaucoup de mal à se projeter. Si vous avez besoin de réaliser des écrans, l'étape de maquettage est primordiale. Le fait d’avoir un produit avec un joli design et de belles couleurs ne suffit pas. Il est primordial d’avoir un produit fonctionnel et adapté à votre métier. C’est à l’application de s’adapter, pas aux utilisateurs. En plus de permettre aux futurs utilisateurs de se projeter, l'étape de maquette a deux fonctions : la première permet au métier de spécifier les règles qui se cachent derrière chaque bouton ou donnée à afficher ; la seconde permet à l'équipe technique de reproduire à l'identique sans interprétation possible.

Un développeur expérimenté : j'insiste sur « expérimenté », cela a un coût. Vous serez tentés de prendre deux juniors au même tarif qu'un senior pour aller deux fois plus vite. Mais ce n'est pas ce qui va se passer. Un développeur senior, par son expérience, fera de meilleurs choix techniques et d'architecture pour anticiper vos besoins. Sinon, vous risquez d'avoir une application difficile à maintenir et à faire évoluer, et dans le pire des cas, repartir de zéro. Vous aurez l'impression d'avoir jeté votre argent par les fenêtres.

Maintenant que vous connaissez les profils de personnes nécessaires pour réaliser le projet de vos rêves, nous pouvons nous poser les questions suivantes :

• Qui et comment allez-vous recruter ces personnes ?
• Comment allez-vous pouvoir jauger leurs compétences ?
• Comment allez-vous les manager ?
• Comment comprendre et avoir le même langage qu'eux ?

Il est nécessaire d'avoir une personne pour chapeauter tout ça. Quelqu'un qui est capable de prendre de la hauteur, qui soit capable de faire le grand écart entre la vision « produit » et une vision « technique ». Quelqu'un capable de choisir les solutions techniques adéquates qui répondent au mieux à votre besoin métier et qui rentrent dans votre budget.

Cette personne a un nom de code : CTO (Chief Technical Officer), ou directeur technique en français. Les rôles du CTO sont multiples et varient selon la maturité du projet.

1.4. Les missions du CTO

Au lancement du projet, le CTO aura un rôle de conseil afin de vous accompagner dans la construction de l'équipe qui réalisera votre projet.

Dans la phase de développement, il veillera au bon déroulement de l'exécution, s'assurant que tout soit fait dans les règles de l'art à tous les niveaux, et évitera au maximum les retards de livraison.

Dans la phase de maintenance et d'évolution, il vous aidera à prioriser et cadrer les nouvelles demandes des utilisateurs, et construira en binôme avec vous la roadmap de votre application.

Vous l'aurez compris, mais je le précise au cas où : c'est la première personne à trouver et votre premier interlocuteur pour échanger sur le produit et l’organisation de la structure de l’équipe nécessaire pour mener à bien votre projet.

Petit conseil pour le trouver : passez soit par une agence spécialisée, soit par vos relations si elles ont un contact avec lequel elles ont déjà travaillé. Au-delà de son expérience, le fit humain est très important. Pensez qu'il sera votre binôme, votre référent, vos yeux dans la technique. La communication entre vous doit être fluide, limpide et sincère.

Lors de la construction de votre équipe, votre CTO n'a absolument pas besoin d'être internalisé (au contraire), ni d'être disponible à 100 % pour vous. La construction d'une équipe ou d'un projet prend du temps et peut avoir des phases plus actives que d'autres. Pour pallier ce problème, commencez par vous mettre d'accord sur 1 à 2 jours par semaine, selon votre budget et la complexité de votre projet. Gardez en tête qu'un projet informatique se fait par petites étapes : ne sortez pas la grosse cavalerie dès le début, vous allez brûler votre énergie et votre argent.

1.5. Equipe en internes ou externes, et pourquoi pas hybride ?

Maintenant que vous avez votre partenaire expert dans le monde des projets informatiques, entrons dans la phase de la création de l'équipe.

Internaliser ou externaliser les équipes ? Ou alors un mix des deux ? Quelles sont les clés qui permettent de se décider ? Je vous dirais qu'il y a deux grands axes : la flexibilité et la souveraineté.

La flexibilité, parce que vous avez besoin de gérer un budget et des besoins qui peuvent varier dans le temps. La souveraineté, parce que le projet développé et les données qu'il contient doivent vous appartenir.

Pour cela, avoir une équipe hybride est souvent la meilleure solution. Mais alors, quel rôle  internaliser et quelles ressources devez-vous externaliser ?

Je vous conseillerais d'internaliser le Product Manager (PM). Cela peut vous étonner car ce n'est pas celui qui codera et apportera de la valeur visible, mais cette personne est une clé de voûte entre la technique et le métier au niveau de l'exécution. Il pourra mettre sur papier l'ensemble des processus, les rationaliser et enfin les optimiser, grâce à la vue macro de l'ensemble de vos services.

Vous garderez la souveraineté de vos règles métiers qui sont l'essence de votre business. Vous comprenez bien que vous n'allez pas confier cette responsabilité à un externe de la société qui gère peut-être d'autres projets, dont celui de votre concurrent direct.

Externaliser les développeurs peut être un bon choix. Attention aux agences : vous perdrez en visibilité sur la qualité du code, sur les ressources allouées, sur l'infrastructure. Pensez dès que possible à reprendre le contrôle, car vous serez dépendant à 100 % de l'agence et vous verrez défiler des devis difficilement négociables, vu que vous n'avez pas vraiment le choix de faire autrement.

Externaliser avec des freelances vous permet de piloter le projet en interne et d'avoir des ressources flexibles. Votre CTO pourra les manager directement et ajuster la capacité en fonction des besoins.

Internaliser un ou deux développeurs est une solution viable dans un second temps. Surtout si vous avez commencé par travailler avec une agence et que vous sentez qu’elle devient un frein pour avancer sur le projet. Internaliser vous permettra de gagner du contrôle et de livrer plus rapidement, encore plus si le projet est complexe. Mais attention, internaliser entraîne un coût fixe quelle que soit la charge de travail.

Veillez à prendre du recul et à vous poser les bonnes questions : « Est-ce que j'ai besoin de faire évoluer mon outil continuellement ? », « Est-ce que cet outil va me faire gagner du temps et, par conséquent, me permettre de générer plus d'affaires par mois pour compenser la charge des équipes techniques ? »

1.6. Boostez votre équipe tech pour plus de vélocité

Maintenant que vous avez une équipe de choc, avec un PM pour la partie produit, un CTO pour la partie technique, ainsi qu'une vision claire des fonctionnalités à développer pour une date limite donnée, il est temps de mettre les mains dans le cambouis.

Encore une fois, qui, et comment ? Bonne nouvelle, ce n'est pas à vous d'y réfléchir, mais à votre CTO de prendre la main. Comme je l'ai dit plus haut, il n'y a pas de recette miracle. Il vous présentera plusieurs solutions selon la taille de votre projet et votre budget.

2. Les choix technique et méthodologiques pour une solution applicative adaptée à votre PME

2.1. Adoptez l'existant, développez l'essentiel

Attention, avoir une équipe interne ou externe est complètement dissocié du fait d'utiliser des solutions existantes ou de tout développer de zéro.

Il est même préférable, dans un premier temps, d'utiliser une solution existante sur le marché et d'adapter vos processus métier. Cela jusqu'à atteindre une limite où il devient nécessaire de développer les spécificités liées à votre métier, tout en conservant les applications tierces pour les actions sans valeur ajoutée.

Par exemple, développer un CRM en partant de zéro n'est pas une bonne idée dans un premier temps, surtout qu'il en existe plein sur le marché. Choisissez celui qui vous paraît le mieux. Utilisez-le pendant un laps de temps qui vous permet de mettre le doigt sur les fonctions clés manquantes et spécifiques à votre métier. Cela vous permettra de valider vos idées, de dépenser du temps et de l'argent sur les fonctionnalités clés uniquement, et de continuer à utiliser les applications tierces, par exemple Brevo ou Mailjet, pour créer des templates d’email et les envoyer.

2.2. Du POC au MVC

Le duo CTO/PM est suffisant dans un premier temps pour monter un POC (Proof of Concept) ou un MVP (Minimum Viable Product). J'utilise volontairement des acronymes pour que vous vous familiarisiez.

Le POC (Proof of Concept) est un projet embryonnaire qui permet de balayer l'ensemble des fonctionnalités dont vous avez besoin, afin de démontrer la faisabilité de votre projet. Il doit couvrir un cas d'usage de bout en bout sans se préoccuper des cas spécifiques. Ce projet n'a pas pour but d'évoluer vers votre application finale; il est conçu pour tester une idée.

Une fois le POC validé, vous pourrez commencer à réfléchir à votre MVP (Minimum Viable Product), c'est-à-dire sélectionner parmi les différentes fonctionnalités celles qui sont clés et donc prioritaires. Votre CTO et votre PM seront là pour vous aider à prioriser. N'oubliez pas, un projet se réalise étape par étape. Pour éviter de tout faire en même temps, fixez-vous un laps de temps, 3 mois maximum. Faites en sorte que l'ensemble des fonctionnalités majeures soient disponibles à la fin de cette période, afin que votre application soit utilisable par vos collaborateurs. Cette étape n'est pas simple mais elle est cruciale. Il y aura des compromis à faire, des fonctionnalités à trancher ou même à abandonner dans un premier temps. Mais si vous ne faites pas cela, dans un an ou deux, votre projet sera toujours en développement et rien ne sera sorti ni utilisable.

2.3. Scrum, Kanban, Shape Up : quelle méthode choisir ?

À cette étape, vous avez une équipe projet, une équipe technique, une roadmap, et un projet en cours de développement. Ce n'est pas pour autant qu'il ne faut plus rien faire jusqu'à la livraison.

Votre équipe projet doit mettre en place les méthodes projets (Scrum, Kanban, Shape Up). Elles ont toutes leurs avantages et inconvénients ; l'équipe projet choisira la méthode adaptée au besoin et à l'équipe.

Quelle que soit la méthode, vous devez avoir une vision claire et précise de l'avancement du projet. Vous devriez pouvoir voir et tester des fonctionnalités de votre application dès les premières semaines de développement. C'est crucial pour être sûr que votre équipe technique garde le cap et vous permette quelques ajustements au fil de l'eau.

2.4. Pourquoi tester est essentiel pour un code de qualité

Alors que vous commencez à avoir des paillettes dans les yeux en voyant votre application prendre vie, il reste encore des étapes clés, en commençant par les tests.

Dites-vous que vos collaborateurs métier ne savent pas tester, et que souvent, ils n'en ont pas le temps, pas l'envie, pas le courage ou besoin d’être accompagné.

C'est ici que le rôle du PM est important : il doit prendre en main les utilisateurs pour les aider et les accompagner. Le but est de sortir l'ensemble des scénarios possibles et de les dérouler sur l'environnement de test.

Attention, pendant les tests, il peut y avoir des ajustements sur les fonctionnalités demandées, mais pas de nouvelles fonctionnalités. Si c'est le cas, une réunion avec l'ensemble des intervenants est nécessaire pour arbitrer. La nouvelle fonctionnalité aura une incidence sur le reste à faire ou sur la date limite, mais à choisir, essayez de tenir la deadline au maximum.

2.5. Organisez vos tests pour des livraisons sans surprises

Lors de vos tests, si l'ensemble des scénarios passent, c'est que l'application fonctionne comme attendu.

C'est une étape cruciale car, les scénarios ayant  été prévus en début  de projet; les équipes métier peuvent avoir oublié les règles appliquées lorsqu'on clique sur tel ou tel bouton, en arrivant vers la fin du projet. Les scénarios sont là pour nous rappeler le comportement attendu, et c'est le résultat de ces scénarios qui vous permet de valider la livraison de votre application.

Il arrive également très souvent, qu’au moment des tests, le métier apporte de nouvelles idées et par conséquent de nouveaux besoin. C’est normal, c’est une bonne chose, cela veut dire qu’il s’approprie l’outil, mais ce n’est pas absolument le moment de les réaliser. Notez l’ensemble des évolutions, prioriser les, et livrez le produit dès que possible.

C’est en production que l’on se rend compte des usages et des réels besoins d’évolutions.

De plus, lorsque vous travaillez avec une agence, c'est encore plus essentiel ! Si vous ne faites pas cela, vous risquez de vous retrouver dans une position délicate où vous devrez batailler avec votre prestataire pour signaler que le comportement que vous observez dans votre application est bien un bug et non une évolution. Même si pour vous il était évident que telle action entraîne tel comportement ; si vous ne l'aviez pas spécifié, l'agence risque de ne pas l'avoir implémenté.

Enfin, dans la tech, le monde n'est pas tout rose, il y a souvent des bugs. Mettre en place un processus avec un outil de ticketing et un modèle de ticket pour exprimer au mieux la reproduction du bug est obligatoire. Cela permet d'avoir l'ensemble des informations claires et reproductibles par les personnes en charge de la correction, et fait gagner un temps considérable sur le nombre de problèmes remontés. Cela apporte aussi de la visibilité à votre PM et CTO sur la quantité de bugs et permet de réaliser un suivi en fonction de leur criticité.

2.6. Pourquoi la documentation est essentielle

Nous sommes presque au bout ; il ne reste que deux étapes importantes pour couvrir l'ensemble du processus. La première, souvent négligée, est la documentation. Il est absolument nécessaire que la documentation fonctionnelle à jour vous soit fournie à la fin de la mission de votre agence, ou tenue à jour par votre PM si les développements sont faits en interne. Si vous ne faites pas cela, vos collaborateurs et vous-même allez passer votre temps à envoyer des emails à l'équipe technique ou à votre PM pour savoir ce qu'il se passe lorsque vous cliquez sur tel ou tel bouton... En plus de la doc fonctionnelle, un documentation technique est tout aussi nécessaire. Elle doit indiquer la procédure d’installation de l’application, présenter l’architecture et les choix techniques, ainsi que l’ensemble le détails de l’ensemble des apis permettant de connecter l’application à d’autres services

2.7. Une bonne formation, pour une adoption réussie

Enfin, la dernière étape : les formations. Ce n'est pas parce que le besoin a été exprimé par vos collaborateurs, ni qu'ils ont vu l'application se construire au fil des mois, qu'ils savent comment l'application fonctionne. Pourquoi ? Parce que le projet dure plusieurs semaines, que la règle métier validée en début de projet leur est sortie de la tête, parce qu'ils ont surtout un métier à côté. Une formation permet de les embarquer pour de bon sur votre application. Et la formation n'est pas que orale ; un document de formation est nécessaire. N'oubliez pas que vos collaborateurs peuvent quitter l'entreprise et que de nouveaux peuvent arriver, et comme vous le savez, les écrits restent. Une bonne stratégie se passe en deux temps. Dans un premier temps, formez vos collaborateurs sur toutes les fonctionnalités qui les concernent directement. Laissez ensuite quelques semaines pour qu'ils utilisent et s'approprient l'application. Par la suite, organisez une formation plus courte en mettant l'accent sur les points nécessitant des éclaircissements, signalés par vos collaborateurs.

3. Une fonction support pour un projet pérenne

Maintenant que vous avez un projet qui tourne, une équipe aux petits soins pour développer les fonctionnalités adaptées aux besoins du métier, avec une documentation à jour, il est temps de mettre en place un processus de support technique. Les personnes en place doivent s'organiser pour réceptionner les demandes venant de vos collaborateurs, qu'il s'agisse de problèmes techniques ou de demandes d'évolution. Des points réguliers avec les responsables des services sont nécessaires pour leur donner de la visibilité sur le traitement de ces tickets ; c'est à ce moment que vous pouvez les prioriser.

4. Sécurité et RGPD : l’essentiel pour rester conforme

Nous n'avons pas abordé l'aspect cybersécurité ni le RGPD, car ces aspects interviennent à chaque étape du projet et un article entièrement dédié à ce sujet serait nécessaire.. Mais s'il faut retenir une chose : vos données doivent être stockées sur un serveur sécurisé, avec un minimum de personnes pouvant y avoir accès ; vos données de test doivent être anonymisées. Les mots de passe doivent être centralisés dans un outil dédié (Dashlane, Okta, etc.), ce qui vous permet de générer des mots de passe sécurisés, de les stocker et de les partager. Si vous stocker des données client ou prospect, vous devez être transparent avec eux et ils doivent pouvoir modifier ou supprimer leurs données personnelles en autonomie ou via l’intermédiaire d’un DPO que vous aurez nommé.

Conclusion : Pour mettre en place une solution applicative adaptée à votre PME, commencez petit et ne brûlez pas les étapes !

En conclusion, la création d'une solution applicative, aussi simple soit-elle, est un métier. Comme pour vos travaux sur votre maison ou les révisions de votre voiture, faites appel à des professionnels.

Commencez petit à petit, que ce soit sur les fonctionnalités à développer ou sur les ressources humaines à recruter. Google et Facebook ne sont pas devenus des géants du jour au lendemain.

Intéressez-vous au projet, suivez-le de près pour comprendre ce qu'il se passe ; vous en aurez besoin pour adapter votre budget.

D'ailleurs, prévoyez votre budget. Vous l'aurez compris, une application n'est pas statique dans le temps. Elle vit ; une fois que les utilisateurs l'auront entre les mains, de nouveaux besoins fonctionnels vont apparaître qui peuvent mettre à jour de la dette technique sans compter le temps nécessaire pour les montées de version des différentes librairies utilisées. C'est pour cela que le MVP couvre les fonctions primaires de bout en bout. Si vous voyez trop grand, le budget risque d'être court, et vous vous retrouverez avec une moitié d'application sans pouvoir la sortir.

‍