Développer en interne ou acheter ? Partie 1

Première partie de notre série consacrée au développement logiciel assisté par l’IA.

Il y a deux ans, lorsqu’une entreprise du secteur événementiel déclarait : « Nous allons le développer nous-mêmes », cette phrase marquait généralement la fin de la réflexion. Quelqu’un lançait l’idée, tout le monde acquiesçait, on faisait les comptes… puis, face aux coûts, l’entreprise finissait malgré tout par opter pour une solution achetée ou proposée sous forme d’abonnement.

Aujourd’hui, cette phrase marque au contraire le début d’une réflexion—et, assez souvent, le point de départ d’un outil qui fonctionne réellement.

Nous le constatons de plus en plus dans nos propres échanges. Un prospect ne choisit pas CrewBrain parce qu’il a développé sa propre solution. Un client nous interroge sur notre API parce qu’il souhaite connecter CrewBrain à son CRM développé en interne. Ces situations restent isolées, mais elles auraient été difficilement imaginables il y a encore quelques années—du moins, pas pour ces raisons.

C’est pourquoi nous consacrons cette série à la question suivante : développer en interne ou acheter ? Nous souhaitons présenter les arguments dans les deux sens. Dans cette première partie, nous examinons ce qui a changé et les situations dans lesquelles une solution développée en interne peut constituer le meilleur choix.

Ce qui a changé

Cela ne signifie pas qu’autrefois, personne ne programmait ses propres solutions. Presque toutes les entreprises qui existent depuis plusieurs années possèdent quelque part un fichier Excel doté de macros qui, en réalité, fait office d’application. Ou encore une base de données Access fonctionnelle à laquelle personne n’a touché depuis 2011, parce que la personne qui l’avait créée ne travaille plus dans l’entreprise.

Ce qui a disparu, c’est la barrière à l’entrée. Aujourd’hui, une personne qui comprend les processus de l’entreprise, mais qui n’a jamais écrit une seule ligne de code, peut créer en un week-end quelque chose de fonctionnel à l’aide des outils d’IA actuels. Il ne s’agit pas seulement de quelques écrans sur lesquels cliquer, mais d’une application exécutée sur un serveur, disposant d’un système de connexion et capable d’enregistrer des données.

Il ne faut pas sous-estimer cette évolution. La personne qui comprend le mieux comment fonctionne la planification dans une entreprise n’est pas le développeur, mais le planificateur. Jusqu’à présent, ces connaissances devaient passer par un cahier des charges, un prestataire et une feuille de route produit. Elles peuvent désormais être intégrées directement dans le logiciel.

Pourquoi cette évolution est plus rapide dans le secteur événementiel

Cette tendance concerne tous les secteurs. Mais dans le nôtre, elle trouve un terrain particulièrement favorable :

Les processus sont réellement différents. Les méthodes de travail d’une entreprise de rigging, d’un constructeur de stands et d’une agence de concerts ne se recoupent que très peu. Pour concevoir un logiciel tel que CrewBrain destiné à ces trois types d’entreprises, il faut le rendre à la fois flexible et suffisamment général. Cela implique cependant qu’il ne corresponde pas toujours à 100 % au quotidien opérationnel de chaque entreprise.

Dans le secteur événementiel, les cas particuliers sont plus souvent de « véritables » cas particuliers. Dans de nombreux secteurs, les entreprises se considèrent comme des exceptions alors qu’elles ne le sont finalement pas. Dans le nôtre, en revanche, les modalités de facturation sont à elles seules si nombreuses qu’un logiciel peut difficilement les couvrir toutes dans leur intégralité—même si nous nous en approchons déjà beaucoup ;).

Les 20 % restants sont souvent les plus déterminants. Les logiciels standard couvrent correctement la majeure partie des besoins. Le reste est pris en charge à l’aide de solutions de secours ou de montages improvisés. C’est précisément là qu’interviennent souvent les développements internes.

Enfin, notre secteur est profondément marqué par la culture du « faire soi-même ». Quiconque soude ses propres adaptateurs et fabrique ses propres flight cases n’hésitera probablement pas à créer également son propre outil de planification.

Les domaines dans lesquels une solution interne est supérieure

En tant qu’éditeur de logiciels, nous pourrions bien entendu dresser ici une liste de risques. Mais commençons par examiner les aspects dans lesquels un outil développé en interne peut être supérieur à une solution achetée—y compris à CrewBrain.

Une adaptation à 100 % : Le logiciel emploie exactement les mêmes termes que ceux utilisés dans l’entreprise. Il n’est pas nécessaire de s’habituer à un vocabulaire différent. Il n’y a ni champs consacrés à des processus inexistants ni rubriques de menu que personne n’utilise. Les besoins véritablement spécifiques—par exemple un rapport personnalisé—peuvent être pris en compte directement.

La rapidité : Il suffit parfois de quelques jours, voire de quelques heures, pour passer d’un besoin à une solution. Un éditeur de logiciels professionnel ne peut souvent pas avancer à cette vitesse. Lorsque nous développons une fonctionnalité, nous la développons pour l’ensemble de nos utilisateurs. Nous devons donc comparer les différents besoins, créer des options de configuration, vérifier la compatibilité avec le produit existant et former notre équipe d’assistance. C’est le prix à payer pour que la fonctionnalité puisse ensuite être utilisée par nos dizaines de milliers d’utilisateurs. Vu de l’extérieur, ce processus peut cependant parfois paraître lent.

Le développement d’un outil permet également de clarifier précisément ses propres processus. Avant de créer une solution, il faut d’abord déterminer exactement quels processus le logiciel doit reproduire. Nous avons accompagné des entreprises qui ont découvert à cette occasion que trois personnes avaient trois conceptions différentes du même processus de planification. Cette prise de conscience peut parfois avoir presque plus de valeur que l’outil lui-même.

Le déclic

Même si notre premier réflexe peut être d’observer une solution développée en interne avec une certaine méfiance, nous avons rapidement compris qu’un tel outil pouvait également nous fournir, en tant qu’éditeur de logiciels, de précieuses informations.

Lorsque l’on demande aux utilisateurs ce dont ils ont besoin dans un logiciel, ils répondent en indiquant ce dont ils pensent avoir besoin. En revanche, leur propre outil montre ce qu’ils utilisent réellement. Après quelques mois d’utilisation, on sait quelle fonctionnalité est ouverte chaque jour et laquelle n’a été développée qu’une seule fois avant d’être laissée à l’abandon.

Jusqu’à présent, nous n’avions pratiquement pas accès à ce type d’informations, sauf lorsque des clients nous transmettaient eux-mêmes des retours détaillés. Pour des raisons de protection des données, nous ne suivons pas le comportement des utilisateurs dans notre logiciel.

Ainsi, lorsqu’un prospect ou un client nous explique qu’il a développé sa propre solution, notre première réaction est la curiosité.

Nous avons donc une demande sincère à vous adresser : si vous avez développé votre propre outil, n’hésitez pas à nous le montrer. Cela peut nous aider à identifier les fonctionnalités que nous pourrions ajouter à CrewBrain ou les aspects qui restent actuellement trop complexes.

Dans la deuxième partie, nous examinerons l’autre aspect de la question* : combien coûte un outil développé en interne pendant sa première, sa deuxième ou sa troisième année—et pourquoi « cela fonctionne » ne signifie pas nécessairement « c’est sécurisé ».*

Cette publication est également disponible en de_DE : liste des langues séparées par une virgule, en_US : dernière langue.