SaaS et IA
Éditeur de logiciel : ce qui change quand vous devez ajouter de l'intelligence artificielle
Vous avez lancé votre logiciel avec une équipe restreinte, et il tourne aujourd'hui chez plusieurs centaines de clients qui ne vous ont jamais rencontré. Être éditeur de logiciel tient en une phrase simple : chaque ligne que vous touchez touche tout le monde en même temps. Quand l'intelligence artificielle arrive au comité de direction, cette contrainte ne disparaît pas, elle se retrouve au centre de la décision. Ce que ça change au quotidien, et où passe la limite entre ce que votre équipe fait seule et ce qu'elle a intérêt à faire construire, se joue sur quelques décisions précises.
Qu'est-ce qu'un éditeur de logiciel, exactement
Un éditeur de logiciel conçoit, développe et possède un produit qu'il vend en licence ou en abonnement, le même produit pour tous ses clients, ou presque. Ce n'est pas une nuance de vocabulaire. Une agence facture du temps passé sur un projet qui appartient ensuite au client, une fois la facture réglée et le contrat refermé. Un éditeur de logiciel garde le produit chez lui, et c'est ce produit, pas des heures de développement, qui génère le chiffre d'affaires mois après mois, année après année, indépendamment du nombre de personnes qui l'ont construit à l'origine.
En France, la plupart des éditeurs de logiciel de taille moyenne ont commencé comme une agence ou comme une équipe technique interne à une entreprise, avant de transformer un outil pensé pour un usage précis en produit vendu à d'autres entreprises du même secteur ou d'un secteur voisin. Cette transition change la manière de décider : une fonction ne se juge plus à l'aune d'un seul client qui la demande bruyamment, mais à l'aune de tous ceux qui devront vivre avec, y compris ceux qui ne l'ont jamais réclamée et qui la découvriront un matin sans avoir rien demandé.
Certains éditeurs de logiciel gardent une activité de service à côté du produit : intégration chez le client, formation des équipes, support renforcé pour les comptes les plus importants. Cela reste un métier d'éditeur tant que la décision finale sur ce que devient le produit appartient à l'éditeur lui-même, et non à la somme des demandes reçues client par client, semaine après semaine, au fil des tickets ouverts par le support technique. Le jour où cette décision glisse vers le client le plus insistant, l'éditeur redevient une agence sans l'avoir décidé.
Vendre un produit ou vendre des jours : le métier d'éditeur de logiciel vu de l'intérieur
Une agence qui vend des jours prend un risque limité dans le temps : le projet livré, le risque de fonctionnement passe au client, qui porte seul les conséquences d'un mauvais choix technique fait en cours de route, longtemps après que la facture a été encaissée et l'équipe redéployée ailleurs. L'agence facture le temps passé, pas le résultat obtenu sur la durée, et cette différence structure toute sa manière de travailler, projet après projet, client après client, sans jamais revenir sur ce qui a déjà été livré.
Un éditeur de logiciel porte un risque d'une autre nature, permanent plutôt que ponctuel : chaque décision prise aujourd'hui continue de produire des effets des années plus tard, chez des centaines de clients à la fois, sans qu'aucun d'eux n'ait revu le contrat ni renégocié quoi que ce soit entre-temps. Un choix d'architecture fait un vendredi soir, sous pression pour livrer avant le week-end, peut coûter cher pendant des années à toute l'équipe qui vient après, sans qu'elle ait eu voix au chapitre le jour où la décision a été prise.
Conséquence concrète : quand un client réclame une fonction, l'agence peut dire oui presque sans réfléchir, puisqu'elle la facture et qu'elle ne concerne que ce client précis, sur ce projet précis. L'éditeur de logiciel doit se poser une question différente avant de répondre : cette fonction sert-elle assez de monde pour justifier qu'elle entre dans le produit et y reste pour toujours, ou vaut-il mieux la refuser, quitte à perdre ce client précis sur ce point précis, plutôt que d'alourdir le produit pour tous les autres.
La base installée : ce qui change quand vous êtes éditeur de logiciel et non prestataire
La base installée désigne l'ensemble des clients qui utilisent déjà votre produit, avec leurs habitudes, leurs données, et souvent leurs propres détournements de fonctions que vous n'aviez pas prévus au départ. Chaque changement que vous poussez en production touche cette base entière le même jour, pas un client à la fois, pas un test progressif choisi par chacun à son propre rythme et selon ses propres contraintes de planning interne.
Un déplacement de bouton qui semble mineur en réunion peut désorganiser des centaines d'utilisateurs qui avaient mémorisé son ancien emplacement, au point de faire remonter plus de tickets support qu'une vraie panne technique. C'est une contrainte que ni une agence ni une entreprise qui construit un outil pour son seul usage interne ne connaît de la même façon : elles n'ont, chacune, qu'un seul jugement à satisfaire à la fois, pas des centaines en même temps, chacun avec ses propres habitudes bien installées.
Ajouter de l'intelligence artificielle dans un produit déjà installé chez plusieurs centaines de clients hérite de la même contrainte, en plus lourd : impossible de la tester uniquement sur le client le plus motivé et de généraliser ensuite sans y avoir pensé pour les autres, ceux qui hébergent leurs données en Suisse, ceux qui refusent tout envoi vers un service tiers, ceux qui n'ouvriront jamais la fonction si elle ne s'intègre pas dans leur écran habituel, sans clic supplémentaire ni page à part.
La dette qui s'accumule dans un produit vendu depuis dix ans
Un produit vendu depuis dix ans porte les traces de dix années de décisions prises sous contrainte de temps, souvent bonnes sur le moment, jamais toutes cohérentes entre elles une fois mises bout à bout. Un module ajouté en urgence pour un client stratégique, un cadre technique abandonné en cours de route mais jamais entièrement retiré, une base de données pensée pour cent clients qui en sert aujourd'hui dix fois plus : chaque strate a sa raison d'être, et personne ne les a choisies ensemble, au même moment, avec la même vision d'ensemble du produit final.
Cette accumulation porte un nom, la dette technique, détaillée dans notre chapitre sur la dette technique. Elle ne se voit pas depuis l'extérieur du produit, seulement de l'intérieur, au moment où quelqu'un doit ajouter une fonction nouvelle et découvre combien l'ancien code résiste à ce qu'on lui demande aujourd'hui, des années après avoir été écrit dans l'urgence par une équipe qui a depuis changé.
Vouloir ajouter une fonction d'intelligence artificielle par-dessus une architecture vieille de dix ans revient souvent à découvrir cette dette au pire moment, celui où elle bloque un projet que le comité de direction attend et qu'il a déjà annoncé en interne, parfois même à des clients. Le diagnostic honnête, avant d'écrire la moindre ligne, gagne plus de temps qu'il n'en coûte, même s'il retarde le démarrage apparent du chantier de quelques semaines.
L'équipe type d'un éditeur de logiciel français de 10 à 150 personnes
Une équipe technique d'éditeur de logiciel de 10 à 150 personnes en France ressemble le plus souvent à ceci : quelques développeurs qui connaissent le produit par cœur pour l'avoir construit ou repris tôt, un responsable produit qui arbitre entre les demandes clients et la vision à trois ans, une équipe support qui remonte ce que les utilisateurs disent vraiment derrière chaque ticket, et parfois une infrastructure gérée à moitié par les développeurs eux-mêmes, faute de personne dédiée au sujet et de budget pour en recruter une.
Cette organisation fonctionne très bien pour faire évoluer un produit existant, corriger un bug, ajouter des fonctions attendues, tenir la promesse faite aux clients année après année sans jamais la trahir. Elle a été construite pour ça, avec le temps et les erreurs, et elle le fait généralement bien, souvent depuis longtemps, avec les mêmes personnes qui connaissent le produit dans le détail, jusque dans ses recoins les plus anciens.
Elle n'a en revanche, la plupart du temps, jamais eu l'occasion de construire un moteur d'intelligence artificielle générative en production, avec ce que ça implique de spécifique : choisir un modèle, gérer des coûts d'appel qui varient avec l'usage réel des clients, éviter qu'une réponse inventée parte chez un client sans aucun contrôle humain derrière. Ce qui manque là est une occasion d'avoir déjà fait ce travail une première fois, avec toutes les erreurs qu'on apprend en le faisant, pas de la compétence.
Ce qui manque le plus souvent à cette équipe quand l'intelligence artificielle arrive à l'ordre du jour
Quand l'intelligence artificielle arrive à l'ordre du jour d'un comité de direction, l'équipe se retrouve souvent devant une demande qu'elle n'a jamais traitée de cette façon : pas seulement coder une fonction de plus dans un produit déjà connu, mais choisir une architecture entière, décider où les données passent et chez quel fournisseur, et savoir répondre à la question qu'un client posera forcément, où va mon information une fois envoyée hors de mes murs et de mon contrôle direct.
Une équipe habituée à faire évoluer un produit sait coder et sait apprendre vite. Ce qui lui manque porte sur l'expérience du sujet précis : avoir déjà vu ce qui casse dans une fonction d'intelligence artificielle en production, avoir déjà mesuré ce que ça coûte réellement à l'usage une fois les mille premiers clients branchés, avoir déjà géré le cas d'un modèle qui répond faux avec la même assurance qu'une réponse juste, sans le signaler.
Cette différence explique pourquoi tant d'éditeurs de logiciel avancent lentement sur le sujet, non par manque de volonté ni par frilosité, mais parce que personne en interne n'a encore fait ce trajet précis une seule fois, du prototype construit en une semaine jusqu'à la production chez des centaines de clients réels qui n'ont pas les mêmes attentes ni les mêmes contraintes. Ce trajet s'apprend en le faisant, pas en le lisant dans une documentation.
Recruter un spécialiste avant d'avoir validé la fonction : une erreur qui coûte cher
Un réflexe fréquent, une fois la décision prise d'ajouter de l'intelligence artificielle au produit, consiste à ouvrir un poste de responsable intelligence artificielle et à lancer le recrutement dans la foulée. Le raisonnement se tient sur le papier : le sujet est stratégique, il mérite une personne dédiée à temps plein, présentée au comité de direction comme la preuve que le sujet avance réellement, mois après mois.
En pratique, ce recrutement prend plusieurs mois avant qu'une personne compétente arrive, engage un salaire fixe avant même de savoir si la fonction imaginée trouvera son public une fois disponible, et place cette personne seule devant un produit qu'elle ne connaît pas encore, avec une architecture et une dette technique qu'elle découvre en même temps que le sujet lui-même. Le coût réel dépasse largement le salaire annoncé sur l'offre d'emploi affichée en ligne.
Valider d'abord si la fonction fonctionne et si des clients l'utilisent vraiment, avant d'engager un recrutement permanent, coûte moins cher et réduit le risque pris par toute l'entreprise. La décision de recruter en interne peut alors se prendre en connaissance de cause, une fois la preuve faite plutôt qu'en pari sur une idée encore théorique jamais confrontée à de vrais utilisateurs payants et à leurs vraies habitudes.
Ce qu'un éditeur de logiciel peut sous-traiter sans perdre la main sur son produit
Un éditeur de logiciel peut sous-traiter une partie importante du travail sans perdre la main sur son produit, à condition de garder trois choses en interne : la décision de ce qui entre dans le produit, la relation avec ses propres clients, et l'accès complet au code une fois le travail terminé, sans dépendance permanente envers celui qui l'a écrit à sa place, quel qu'il soit. Ces trois garanties se négocient avant la signature, pas après, une fois le travail commencé.
Deux formes de sous-traitance existent pour la partie intelligence artificielle. La première consiste à faire développer directement dans le dépôt de code de l'éditeur, avec ses propres développeurs en binôme sur le sujet : nous travaillons ainsi avec une équipe qui développe dans votre dépôt, avec vos développeurs, ce qui laisse le produit entièrement entre les mains de l'éditeur du premier au dernier jour du projet, sans boîte noire cachée quelque part dans le code.
La seconde consiste à faire construire un composant autonome que l'éditeur branche à son produit et revend sous sa propre marque, sans que le client final sache qu'une équipe extérieure l'a construit quelque part en amont. Les deux formes protègent la propriété du produit, elles répondent simplement à deux situations différentes selon le temps disponible en interne et l'ambition de la fonction visée par l'éditeur.
La question de la propriété du code
La question de la propriété du code se pose dès le premier échange avec un prestataire extérieur, et elle mérite une réponse écrite avant que le travail commence, pas une fois le projet livré et la facture envoyée. En droit français, sans clause de cession de droits explicite dans le contrat, l'auteur du code en garde certains droits, même s'il a été payé pour l'écrire du premier au dernier caractère, ce que beaucoup d'éditeurs découvrent trop tard.
Un contrat sérieux prévoit une cession complète des droits patrimoniaux sur le code écrit pour vous, avec le code source livré dans son intégralité, pas seulement un exécutable fermé que vous ne pouvez ni lire ni faire évoluer par une autre équipe le jour où vous le décidez, quelle que soit la raison de ce changement de prestataire, amicale ou non. Ce détail, souvent glissé en une ligne dans les conditions générales, mérite d'être lu avec attention avant toute signature.
Posez la question directement à tout prestataire avant de signer : qui possède le code une fois le projet terminé, sous quelle forme il vous est livré, et si vous pouvez le faire reprendre par une autre équipe sans dépendre de lui pour toujours, même des années plus tard. Une réponse évasive sur ce point mérite d'être prise au sérieux avant de s'engager, quelle que soit la qualité annoncée du travail sur le papier.
Le moment où un éditeur de logiciel a intérêt à faire construire plutôt que construire seul
Un éditeur de logiciel a intérêt à faire construire plutôt que construire seul quand trois signaux se rejoignent : personne en interne n'a déjà mené ce type de projet, le sujet presse alors qu'un recrutement prendrait plusieurs mois avant de porter ses fruits, et la fonction reste encore à valider avant de justifier un investissement permanent en interne pour la maintenir dans la durée, année après année.
L'inverse existe aussi. Quand la fonction devient le cœur du produit, celle qui justifie le prix payé par les clients et qui distingue le produit de ses concurrents, elle a vocation à revenir en interne à moyen terme, portée par une équipe qui la connaît de l'intérieur. Rien n'empêche de commencer avec une aide extérieure dans le dépôt du produit, puis de reprendre la main une fois la fonction stabilisée et son intérêt prouvé auprès des clients réels, pas seulement supposé en interne.
Le choix ne se fait pas une fois pour toutes, il se réévalue au fil du temps. Beaucoup d'éditeurs de logiciel commencent par faire valider une première version avec une aide extérieure, avant de décider, chiffres à l'appui, s'ils recrutent pour prendre le relais en interne ou s'ils préfèrent continuer avec la même équipe externe sur la durée, tant que ça fonctionne pour les deux côtés. Rien n'oblige à trancher cette question dès le premier contrat signé.
Ce que nous construisons avec les éditeurs de logiciel
Nous développons des fonctions d'intelligence artificielle directement dans le produit d'éditeurs de logiciel, dans leur dépôt de code, avec leurs propres développeurs quand ils en ont, sans jamais prendre la place de leur équipe ni imposer une méthode de travail étrangère à la leur, ni un outil qu'ils devraient ensuite apprendre à maintenir seuls une fois le projet terminé. Notre objectif reste le même du premier au dernier jour : que le produit continue de leur appartenir entièrement.
C'est ce que nous avons fait pour Cortex OS : intégrer un moteur d'intelligence artificielle générative dans un produit déjà vendu, sans que l'éditeur perde la main sur son code à aucun moment du projet. Le détail de ce travail est sur notre page cas Cortex OS, avec ce qui a été construit et comment, du premier échange jusqu'à la mise en production chez leurs clients.
Si vous êtes éditeur de logiciel et que le sujet de l'intelligence artificielle avance dans vos discussions internes plus vite que votre certitude sur comment vous y prendre, notre guide sur l'intelligence artificielle dans un logiciel édité détaille les questions à trancher avant de vous lancer. Nous écrire directement fonctionne tout aussi bien si vous préférez en parler à quelqu'un plutôt qu'à une page.
Questions fréquentes
Qu'est-ce qu'un éditeur de logiciel ?
Une entreprise qui conçoit, développe et possède un produit logiciel vendu en licence ou en abonnement, le même produit, ou presque, à tous ses clients. Elle se distingue d'une agence qui vend du temps de développement sur des projets qui appartiennent ensuite au client, et d'une entreprise qui construit un outil pour son seul usage interne, sans intention de le vendre à d'autres. Un éditeur de logiciel tire son chiffre d'affaires du produit lui-même, pas des heures passées à le construire, ce qui change entièrement la façon dont il arbitre entre les demandes reçues chaque semaine.
Quelle différence entre un éditeur de logiciel et une agence de développement ?
Une agence facture des jours de travail sur un projet qui devient la propriété du client une fois livré, et son risque s'arrête à la livraison, quoi qu'il se passe ensuite. Un éditeur de logiciel garde le produit chez lui, le vend au même format à de nombreux clients à la fois, et porte chaque décision technique pendant des années, sur toute sa base installée en même temps. Une agence peut dire oui à la demande d'un seul client sans grande conséquence, un éditeur doit se demander si cette demande sert assez de monde pour entrer durablement dans le produit.
Combien coûte l'ajout d'une fonction d'intelligence artificielle dans le produit d'un éditeur de logiciel ?
Chez nous, un développement mené directement dans le dépôt de code d'un éditeur de logiciel, avec ses propres développeurs, se chiffre en plusieurs dizaines de milliers d'euros. Ce qui fait varier le montant : la taille de la base installée à ne pas perturber, le nombre d'intégrations déjà en place dans le produit, et si le travail part d'un code propre ou d'une dette technique importante à traverser d'abord. Une brique autonome que vous branchez et revendez sous votre marque suit une logique de prix distincte, discutée selon ce qu'elle doit accomplir précisément.
Un éditeur de logiciel doit-il recruter un spécialiste en intelligence artificielle avant de se lancer ?
Pas avant d'avoir validé que la fonction sert vraiment vos clients, une fois disponible dans le produit. Un recrutement prend plusieurs mois, engage un salaire fixe, et place la personne seule devant un produit qu'elle découvre en même temps que le sujet. Faire valider une première version avec une aide extérieure, dans votre dépôt de code, coûte moins cher et réduit le risque de départ pour toute l'entreprise. La décision de recruter en interne se prend ensuite en connaissance de cause, une fois la preuve faite plutôt qu'en pari sur une idée encore théorique.
Peut-on faire développer une fonction dans son produit sans perdre la propriété du code ?
Oui, à condition que le contrat prévoie une cession complète des droits sur le code écrit pour vous, avec livraison du code source dans son intégralité, pas seulement d'un exécutable fermé que personne d'autre ne peut faire évoluer ensuite. Posez la question avant de signer : qui possède le code une fois le projet terminé, et pouvez-vous le faire reprendre par une autre équipe sans dépendre du prestataire pour toujours. Une réponse floue sur ce point précis mérite d'être prise au sérieux avant tout engagement contractuel.
Qu'est-ce qu'une brique d'intelligence artificielle qu'un éditeur peut brancher à son produit ?
C'est un composant autonome, construit en dehors de votre produit puis branché dessus, que vous revendez ensuite sous votre propre marque sans que vos clients sachent qu'une équipe extérieure l'a développé quelque part en amont. Elle convient quand vous voulez avancer vite sans mobiliser vos développeurs sur un sujet qu'ils n'ont jamais traité auparavant. Elle diffère d'un développement mené directement dans votre dépôt de code, qui implique vos équipes du premier jour et laisse encore plus de contrôle en interne sur le résultat final.
Quand un éditeur de logiciel a-t-il intérêt à faire construire plutôt que recruter en interne ?
Quand trois signaux se rejoignent : personne en interne n'a déjà mené ce type de projet, le calendrier ne permet pas d'attendre plusieurs mois de recrutement avant de commencer, et la fonction reste à valider avant de justifier un investissement permanent. Une fois la fonction devenue centrale dans le produit et son intérêt prouvé auprès des clients, rien n'empêche de reprendre la main en interne, avec une équipe qui la connaît déjà de l'intérieur pour l'avoir vue construite et vivre sous ses yeux.
