Développer en interne ou acheter ? Partie 2

Deuxième partie de notre série consacrée au développement logiciel assisté par l’IA

Dans la première partie de notre série, nous avons examiné les domaines dans lesquels un outil développé en interne peut être supérieur à une solution achetée. Passons maintenant à l’autre côté de la question.

Précisons tout d’abord un point afin d’éviter tout malentendu : cette liste n’a pas pour objectif de dissuader qui que ce soit de développer son propre logiciel. Nous constatons chez nos clients que les outils d’IA permettent d’améliorer l’efficacité et de simplifier la planification du personnel ainsi que les processus opérationnels—et nous considérons cela comme une évolution positive.

Il s’agit plutôt ici des coûts et des responsabilités qui sont presque toujours absents des premières estimations, car ils n’apparaissent pas au début du projet, mais plus tard.

Le développement est la partie la moins coûteuse

Aujourd’hui, il est possible de développer un outil en un week-end. Mais il faudra ensuite l’exploiter pendant plusieurs années.

Entre les deux, il y a les serveurs, les sauvegardes et, au moins une fois par an, un test permettant de vérifier qu’une sauvegarde peut réellement être restaurée en cas d’urgence. Il faut également mettre à jour les composants intégrés au logiciel et l’adapter lorsque quelque chose change dans l’entreprise. Les nouveaux collègues doivent être formés, et les utilisateurs internes ont besoin d’aide lorsque quelque chose ne fonctionne pas au début de leur journée de travail.

Tout cela continue bien après que le projet de développement interne a cessé d’être passionnant. C’est précisément cette partie que l’on paie également lorsque l’on choisit un prestataire tel que CrewBrain.

Lorsque la personne qui a créé l’outil s’en va

Revenons au fichier Excel avec macros évoqué dans la première partie. Dans les faits, un outil développé en interne appartient à la personne qui l’a créé. Si cette personne quitte l’entreprise, change de service ou s’absente pendant une période prolongée, l’entreprise risque de se retrouver avec un logiciel dont personne d’autre ne comprend le fonctionnement interne.

L’IA pourra certes expliquer le logiciel à la personne qui prendra la relève, mais elle n’en assumera pas la responsabilité.

« Cela fonctionne » ne signifie pas « c’est sécurisé »

En tant qu’éditeur de logiciels, cette question nous préoccupe depuis l’apparition d’outils d’IA performants.

Pour nous, cependant, la sécurité n’a jamais été une problématique propre à l’IA. Elle constitue depuis toujours un principe fondamental. Lorsqu’on gère les données de dizaines de milliers de personnes, on se pose les mêmes questions avant chaque nouvelle fonctionnalité : qui est autorisé à consulter ces informations ? Où les données sont-elles stockées ? Que se passe-t-il en cas de problème ?

Il ne s’agit pas simplement de faire preuve de diligence. C’est une obligation fondamentale pour tout éditeur de logiciels.

Ce que l’IA a changé n’est pas le principe, mais la vitesse. Aujourd’hui, le code est produit plus rapidement qu’il ne peut être contrôlé—et c’est précisément là qu’une faille apparaît.

Ce phénomène peut également être mesuré. Depuis 2023, Veracode teste régulièrement la sécurité du code produit par des modèles d’IA. Dans son rapport de mars 2026, l’entreprise indique que plus de 95 % du code est syntaxiquement correct, mais qu’il n’est sécurisé que dans environ 55 % des cas. Ce taux ne s’est pas amélioré de manière significative depuis le début des tests, alors même que les modèles sont devenus nettement plus performants sur le plan fonctionnel.

Les résultats les plus faibles concernent précisément les types de vulnérabilités difficiles à repérer dans un système en fonctionnement—par exemple, des données saisies par les utilisateurs susceptibles de causer des dommages. Cela peut être acceptable pour un outil interne ne contenant aucune donnée sensible. En revanche, la situation devient beaucoup plus problématique pour un outil doté d’un système de connexion, éventuellement accessible depuis Internet et contenant des données relatives au personnel.

Développé rapidement ne signifie pas stable

Dans le rapport DORA 2025, 90 % des personnes interrogées indiquent utiliser l’IA dans leur travail, et plus de 80 % estiment qu’elle les rend plus productives.

Une relation reste toutefois négative : celle avec la stabilité. Le volume considérable de contenu généré par l’IA entraîne davantage d’incidents, en particulier lorsque les dispositifs de sécurité font défaut. Il s’agit notamment des tests automatisés, d’une gestion rigoureuse des versions et, bien entendu, d’un retour immédiat lorsqu’un élément cesse de fonctionner.

La principale conclusion du rapport est la suivante : l’IA ne répare pas une équipe, elle amplifie ce qui existe déjà.

Or, un projet réalisé en un week-end ne dispose généralement pas de ce filet de sécurité. Il ne s’agit pas d’un reproche adressé à l’IA ou à son utilisation. C’est simplement le constat que la réussite d’un projet utilisant l’IA dépend souvent de l’environnement dans lequel celle-ci est employée.

Le véritable enjeu : les données sensibles

Un logiciel tel que CrewBrain contient rarement des données anodines dont la divulgation publique serait sans conséquence. On y trouve des adresses, des dates de naissance, des temps de travail enregistrés et souvent même des photos de pièces d’identité ou de certificats.

Lorsque ces données sont confiées à un prestataire tel que CrewBrain, un accord de traitement des données définit les responsabilités de chacun. Dans le cas d’un développement interne, toute la responsabilité reste au sein de l’entreprise :

• La manière dont les données sont protégées doit être documentée par l’entreprise et pouvoir être démontrée en cas de besoin.
• Les demandes d’accès, de rectification et de suppression doivent pouvoir être traitées techniquement. Une politique de suppression conforme à la législation ne se limite pas à cocher une case indiquant qu’un élément a été supprimé.
• En cas de violation de données, le délai de notification est de 72 heures. Encore faut-il être en mesure de détecter l’incident. Les grands prestataires tels que CrewBrain disposent pour cela de systèmes de journalisation et de surveillance. Ce n’est généralement pas le cas d’un projet individuel réalisé en un week-end.

La législation ne reste pas immobile

L’obligation d’enregistrer le temps de travail existe déjà en Allemagne et depuis plus longtemps encore à l’échelle européenne. Les modalités précises qu’elle devra prendre à l’avenir restent toutefois incertaines. Un projet de réforme de la loi allemande sur le temps de travail prévoit un enregistrement électronique assorti de périodes transitoires échelonnées, mais il n’a pas encore été adopté.

Ce n’est qu’un exemple parmi tant d’autres. Le salaire minimum et sa documentation, les délais de conservation, les règles relatives à la mise à disposition de personnel ainsi que les exigences issues des conventions collectives évoluent constamment—parfois progressivement, parfois de manière importante.

Pour nous, suivre ces évolutions fait partie du travail quotidien, puisque nous devons de toute façon le faire pour nos utilisateurs. Quiconque développe son propre logiciel assume seul cette responsabilité—non pas une seule fois lors du développement, mais de manière permanente.

Les petits détails qui deviennent pénibles avec le temps

Enfin, certains aspects passent totalement inaperçus dans la première version, mais finissent ensuite par coûter un peu de temps et d’argent chaque mois.

Les jours fériés qui diffèrent selon les Länder allemands. Les fuseaux horaires lors de tournées dans plusieurs pays. L’absence de réseau dans certaines salles. Qui est autorisé à consulter quelles informations dans le système, et de quelle manière ? Une équipe de plusieurs centaines de personnes souhaitant pointer simultanément à 7 heures un samedi matin et provoquant ainsi une surcharge du serveur. Une mission supprimée par erreur qu’il faut restaurer.

Tous ces problèmes peuvent être résolus. Mais chacun d’entre eux demande une nouvelle fois un peu de temps.

Les questions à se poser avant de développer son propre logiciel

Plutôt que de formuler une recommandation, nous préférons proposer quelques questions à examiner avant de prendre une décision :

1. Quelle quantité de données personnelles sera finalement stockée dans l’outil ?
2. Suis-je disposé et en mesure d’assumer la responsabilité si des données sensibles relatives au personnel ou à l’entreprise sont rendues accessibles sans autorisation à la suite d’une erreur ?
3. Que se passe-t-il si l’outil tombe en panne de manière imprévue le jour d’un événement ? Est-ce seulement gênant, ou également coûteux ?
4. Qui poursuivra le travail si la personne qui a créé l’outil n’est plus présente ?
5. Qui se chargera de la conformité, par exemple en matière d’enregistrement du temps de travail ?
6. Mes processus opérationnels sont-ils réellement si particuliers qu’aucun logiciel standard ne peut en couvrir la majeure partie ?
7. Existe-t-il un budget pour l’exploitation du logiciel—ou uniquement pour son développement ?

La règle générale est la suivante : plus l’outil contient de données personnelles et plus une panne serait coûteuse, plus il est judicieux d’acheter une solution existante. Plus le cercle des utilisateurs est restreint, plus le développement interne peut être pertinent.

Et assez souvent, la bonne réponse est aussi : les deux.

La troisième partie explique où se situe la frontière entre une solution développée en interne et une solution achetée, ainsi que les mesures que nous prenons, en tant que prestataire, pour que cette combinaison fonctionne correctement.

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