Discussion :

[nikles007]

Bonjour,

Prenons l'exemple d'une vieille entreprise qui utilise un logiciel, qu'elle développe elle même.

Soucieuse de se reconcentrer sur son cœur de métier, elle souhaiterait se délester du développement du logiciel qu'elle utilise, et le confier à une entreprise tiers, une SSII en forfait par exemple.

D'après vous, quelles seraient les freins à une telle démarche ?

J'entrevois des problèmes de spécifications techniques qui pourraient être incomplètes, et du coup générer des avenants couteux.
Des problèmes pour définir ce qu'est un bug mineur, majeur, ... définir les délais de livraisons ...

D'autres idées, sites, ... ?

[Logan Mauzaize]

Je n'ai jamais eu l'expérience d'une application qui passe du mode développement interne au mode forfait externalisé directement. En général, on passe par une étape d'assistance technique interne, puis l'assistance technique externe et enfin le forfait. Ca permet de faire la transition en douceur et de trouver également un équilibre pour le client.


Le frein principale sera le dialogue établi. Pour le reste c'est contractuel. Je préconiserai une démarche "agile", souviron t'en feras surement une très bonne description mais voici comment je vois les choses :

1. un développement en cycle
2. des cycles très courts (~1 mois)
3. un contrat par cycle
4. des relectures et des tests effectués par des vrais utilisateurs
5. des utilisateurs disponibles, au minimum, plusieurs fois par semaine.
6. des réunions régulières avec les membres de l'équipe de prestation

Bien sûr si les prestataires sont sur site, voir dans les mêmes bureaux que les utilisateurs ca facilitera les choses dans un premier temps. Quand les choses sont plus matures, c'est plus facile de se "détacher".

[gangsoleil]

D'après vous, quelles seraient les freins à une telle démarche ?

Le fait que l'entreprise qui recupere le code va mettre des annees a monter en competences sur le logiciel, car il n'y a pas de doc, ou trop, ou mal ecrite, ou ils n'ont pas envie de la lire, ou autre.
Et puis il faut aussi voir ce que l'entreprise fera des gens qui ont developpe le logiciel : s'ils sont a plein temps pour former la SSII, le cout va etre eleve, et il faut le prevoir. S'ils font autre chose, soit la SSII peut les deranger, et il faut compter une bonne partie de leur temps dessus (mais ca decroit, enfin normalement), soit la SSII se debrouille toute seule, et on revient au point precedent.

[nikles007]

Je rappelle que la question de savoir si cette entreprise doit ou ne doit pas externaliser le dev de son logiciel ne se pose pas.
Elle n'a pas les compétences pour faire ce logiciel elle-même.
Elle doit externaliser ce logiciel.
Ce sera pour elle un soulagement.

Je note donc, comme freins:

- Le dialogue entre les deux entités, les problèmes de compréhensions (méthodes agiles permettrait de rapprocher les deux entités)

- Difficultés à s'approprier le code déjà fait.

- Problème RH (que faire des développeurs existants ? seront ils dérangés ?)

- problèmes de spécifications qui pourraient être incomplètes

- Définitions communes (qu'est ce qu'un bug, ...)

- Modalités (délais de livraison, délai de correction d'un bug ,..)



D'autres ont ils des idées ? peuvent ils partager leur expérience ?

[Graffito]

Le principal problème du dévellopement au forfait d'un logiciel spécifique est qu'une fois la recette effectuée les équipes du prestataires vont s'égayer sur d'autres projets et souvent d'autres SSII.

Faire alors évoluer le logiciel au bout d'un ou 2 ans devient alors hasardeux si aucun des développeurs initiaux ne peut se consacrer aux modifications. Pour se garantir de cet ecueuil, on peut demander un maximum de documentation, mais avec un impact certain sur les coûts.

Sinon , il vaut mieux choisir des prestataires qui sont des concepteurs/éditeurs de logiciels et qui auront un turnover plus limité que des SSII qui montent puis démantèlent des équipes au gré des projets apportés par leurs commerciaux

[souviron34]

D'après la question, je vois un petit problème dès le départ :

Soucieuse de se reconcentrer sur son cœur de métier, elle souhaiterait se délester du développement du logiciel qu'elle utilise, et le confier à une entreprise tiers, une SSII en forfait par exemple.

Dans ton écriture, le coeur de métier n'est donc pas le logiciel..

Pourtant, d'après ta description, le logiciel est cependant un élément déterminant.. Ou me trompe-je ??

Il faut d'abord et avant tout éclaircir ce point..

Exemples :

• une entrerpise d'électronique se sert d'AutoCad. Dans ce cas effectivement le logiciel n'est PAS le coeur du métier.
  
• une entreprise d'électronique fabrique un matériel avec un logiciel intégré. Dans ce cas le logiciel EST une partie du coeur du métier..

D'après vous, quelles seraient les freins à une telle démarche ?

Les intervenants ci-dessus ont bien dégagé les principales lignes

Mais tout dépend de la vraie réponse à la question que je pose ci-dessus..

Si c'est vraiment pas le coeur du métier, alors oui on peut faire appel à une SSII. Dans ce cas , comme le dit Graffito, préférer de très loin une petite structure ou un indépendant très qualifié, quitte à le payer cher...

Le turn-over et la gestion des grosses SSII ne garanti ni la pérennité, ni même l'achèvement, sans parler de coûts prohibitifs pour des modifications.. Et le prix mis à avoir une petite structure très qualifiée sera largement récupéré par la qualité et du produit, et vraisemblablement du SAV.


Ensuite, le principal frein est de trouver une personne compétente et disposant de temps au sein de l'entreprise, et si possible avec une grande anciennenté dans l'entreprise.. Cela est absolument nécessaire pour obtenir un outil donnant satisfaction et expliquer les parties/corrections de bugs/patchs/défauts/avantages dans le logiciel existant... l'historique, quoi.. Sinon il faudra se retaper les X années (10 ? 20 ?) de "débuggage" et "fine-tuning"..


En ce qui concerne les modalités, là encore tout dépend de la réponse à la première question... Les délais de corrections de bugs, les définitions de bugs majeurs ou mineurs, etc, dépendent et du domaine (un bug dans le domaine médical est en général soumis à un délai de 48h max, un dépannage à un délai de 4h... Mais un bug sur un logiciel style AutoCAD peut avoir un délai de 6 mois. ) et de l'importance du logiciel (si tu fabriques une aile d'avion, une erreur sur les instructions de pilotage de la machine-outil va être catastrophique, et impliquer des frais (pénalités ou dépenses pour refaire) gigantesques.. )


Enfin, comme conclusion, et là encore cela dépend de la réponse à la première question, quand tu dis "cela sera un soulagement', de quel point de vue se place-t-on ?? financier court-terme, financier long-terme, RH ? Parce que , comme avec le "cloud" dont on nous bassine les oreilles, les enjeux d'un "soulagement" peuvent dans certains cas conduire à la faillite...

[Caro999]

- Difficultés à s'approprier le code déjà fait
- Problème RH (que faire des développeurs existants ? seront ils dérangés ?)

Traditionnellement, les développeurs (ou une partie des développeurs) peuvent faire partie du contrat et être transférés vers la société qui sera en charge de développer le logiciel après son externalisation. Les 2 sociétés devront contractualiser un ensemble de mesures permettant de pérenniser les emplois dans la structure accueillant les développeurs: négociation des salaires, des bonus, des conditions de travail, avantages, mutuelle, etc... Il vous faudra néanmoins conserver des ressources capables de driver les relations contractuelles.

- Le dialogue entre les deux entités, les problèmes de compréhensions (méthodes agiles permettrait de rapprocher les deux entités)
- problèmes de spécifications qui pourraient être incomplètes

- Définitions communes (qu'est ce qu'un bug, ...)

- Modalités (délais de livraison, délai de correction d'un bug ,..)

Pour toutes ces parties, vous pouvez vous assurer le support ponctuel d'un consultant AMOA qui vous aide à passer le cap, à négocier, développer, documenter, déployer les procédures nécessaires et qui "vous tient" la main jusqu'à ce que le contrat soit en place et que vous vous sentiez à l'aise avec la poursuite de vos relations contractuelles avec la nouvelle société.

Vous pouvez également demander à ce que les sources documentés ainsi que toutes les documentations et procédures de construction de l'appli soient régulièrement déposés chez des tiers de confiance (escrow agreement) pour qu'ils puissent vous être remis en cas de défaillance du sous-traitant.

[e-ric]

Traditionnellement, les développeurs (ou une partie des développeurs) peuvent faire partie du contrat et être transférés vers la société qui sera en charge de développer le logiciel après son externalisation. Les 2 sociétés devront contractualiser un ensemble de mesures permettant de pérenniser les emplois dans la structure accueillant les développeurs: négociation des salaires, des bonus, des conditions de travail, avantages, mutuelle, etc... Il vous faudra néanmoins conserver des ressources capables de driver les relations contractuelles.

Les développeurs externalisés peuvent aussi aller se faire voir ailleurs, après tout leur boîte les a lâché, cela me fait penser au contrat en reprise de charge (FM) où la clause de reprise des salariés était impossible à mettre en oeuvre faute de "survivants", la pérennisation est toute relative. Les contrats d'embauche des SSII sont rarement aussi avantageux que celles de leurs clients.

[Aqualys]

Bonjour,

Prenons l'exemple d'une vieille entreprise qui utilise un logiciel, qu'elle développe elle même.

Soucieuse de se reconcentrer sur son cœur de métier, elle souhaiterait se délester du développement du logiciel qu'elle utilise, et le confier à une entreprise tiers, une SSII en forfait par exemple.

D'après vous, quelles seraient les freins à une telle démarche ?

J'entrevois des problèmes de spécifications techniques qui pourraient être incomplètes, et du coup générer des avenants couteux.
Des problèmes pour définir ce qu'est un bug mineur, majeur, ... définir les délais de livraisons ...

D'autres idées, sites, ... ?

2 points à éclaircir :

- Il s'agit de reprendre l'application actuelle et de la maintenir ou de refaire une nouvelle application ?
- De quel type d'application s'agit-il ?
( un site web, un automate de production, une appli de gestion,... )
( nombre d'utilisateurs, volumétrie des données, ... )
( architecture technique, logiciel, ... )
- Quid de l'exploitation ?

Sans connaître ces quelques informations, il est optimiste de définir qui peut répondre à cette offre et quels peuvent être les problèmes.