Trois devis différents : agence, freelance et software house — c'est quoi une software house et quand est-ce avantageux ?

Avant de trancher, étudiez ces trois critères : 1) Le risque d'erreur financière : si le système calcule de mauvaises cotes ou des prix erronés, qui assume les pertes ? 2) La vision future : ce portail a-t-il vocation à devenir le logiciel de production central de votre entreprise d'ici 2 ans ? 3) L'indépendance : si vous changez de prestataire, aurez-vous une documentation technique complète et exploitable par une autre équipe ? Si ces éléments sont critiques pour vous, la software house est le choix incontournable.

Il y a deux ans, on a payé 4 000 EUR pour un outil de calcul similaire et on s'est mis d'accord avec un freelance. Le système marchait mais le gars qui l'a développé est passé en CDI dans une boîte corporate et a lâché le projet. Comme y'avait aucune doc, personne n'a pu faire ne serait-ce qu'une simple mise à jour de taxe dans le code. Au final on a dû lâcher 11 000 EUR et tout faire réécrire de zéro par une software house ; le budget de départ est parti en fumée.

Les devis des software houses corporate ne riment pas toujours avec ingénierie irréprochable. Y'a plein de boîtes qui facturent 13 500 EUR et qui, après la phase d'analyse, refilent le vrai boulot de codage à des stagiaires ou à des prestataires pas chers trouvés à l'extérieur. Faites inscrire au contrat à l'avance quels ingénieurs de quel niveau vont réellement développer le projet et avec qui vous ferez les réunions de sprint.

les agences sont super fortes sur les projets vitrine mais dès qu'il y a une base de données complexe et des formules, la plupart du temps elles essaient de s'en sortir en bricolant des plugins. et le freelance, comme il bosse seul peut disparaître du jour au lendemain en cas de maladie ou de surcharge... si votre budget le permet, une software house vous met l'esprit tranquille.

Combien de frais de service SLA mensuels la software house qui vous fait le devis demande-t-elle pour le support et la maintenance après la mise en production ? En général ce genre de boîtes propose un contrat de maintenance mensuel après la livraison ; en planifiant votre budget, avez-vous ajouté ces éventuels frais d'exploitation à côté du coût d'installation initial ?

Nous, au début, on avait fait faire notre portail côté logistique par notre agence de design. L'interface était top mais dès que 15 utilisateurs ont commencé à valider des commandes en même temps, la base de données s'est bloquée. Parce que l'agence avait abordé ça avec une logique e-commerce. Au final on s'est mis d'accord avec une boîte de logiciels, on a fait refaire toute l'architecture de zéro et c'est seulement comme ça qu'on a réglé le problème.

quand on s'accorde avec une software house la propriété du code écrit nous appartient-elle directement ? bon si plus tard on arrête de bosser avec eux est-ce qu'on peut transférer le projet à une autre boîte et continuer à le développer ?

Réglez la question de la propriété du code source dès le départ. Le contrat doit stipuler que l'accès au dépôt de code et la propriété intellectuelle seront cédés sans condition à votre entreprise. Peu importe le prestataire que vous choisissez, sans protocole de livraison du code, ne versez pas de paiement global en dehors de l'avance.

Je suis entièrement d'accord. Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Merci d'avoir écrit cela, c'est exactement ça. Les décisions hâtives finissent par être corrigées six mois plus tard.

Quand on essaie de tout changer en même temps, rien ne prend. Je le note au cas où.

Ne manquez rien : L'erreur commise du côté de software house est généralement réversible, mais coûteuse.

Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

La réponse ci-dessus va droit au but. Ce que tout le monde fait ne signifie pas que c'est la bonne chose.

Essayer de faire cela seul est la voie la plus coûteuse. Je le note au cas où.

Je suis d'accord.

Chez nous, ça s'est passé comme ça. Si le périmètre s'agrandit, il faut augmenter soit le délai, soit le budget. Il n'y a pas de troisième option.

Je le note au cas où.

Je suis d'accord en partie, pas en partie. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

Chaque « on verra ça plus tard » en réunion signifie du travail non chiffré. Bien sûr, cela change si votre situation est différente.

Je vous conseille de ne pas vous presser. Commencez par un petit test ne vous engagez pas sur tout d'un coup.

Je suis passé par là laissez-moi vous raconter. Quand on essaie de tout changer en même temps, rien ne prend.

Voilà désolé si je me suis étendu.

J'ai travaillé longtemps sur ce sujet. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même. J'espère que cela vous sera utile.