Vous cherchez un prestataire pour développer une application ?
Celui-ci va sans doute vous inonder de termes inconnus au bataillon.
Pas de panique !
Aujourd’hui, on vous éclaire sur la notion de framework, et plus précisément ce qu’on appelle les frameworks “maison” qui sont parfois utilisés dans les développements.
Bonne pratique ou mauvaise idée ?
On ouvre le débat !
Commençons par le commencement !
Pour faire votre application, les développeurs vont s’appuyer sur un langage, comme Java ou C#.
Puis pour différentes raisons, comme l'accélération des développements, ils peuvent également utiliser un framework.
Un framework, traduit littéralement, ça nous donne un cadre de travail. Pour faire simple, c'est un ensemble de composants qui structure votre application et qui contraint la manière dont vous allez la développer
Pour en savoir plus, n’hésitez pas à aller écouter notre podcast à ce sujet ou à lire notre article dédié.
Les frameworks peuvent être officiels, comme par exemple .NET, le framework de C# qui est développé par Microsoft.
Ils peuvent aussi être open source, c’est-à-dire qu’ils sont libres d’être utilisés et améliorés par tous. C’est par exemple le cas Symfony, framework star du langage PHPLangage de programmation s’exécutant côté serveur et permettant la création dynamique de pages web ou d'APIs., créé par SensioLabs.
Enfin, les frameworks peuvent être “maison”, c’est-à-dire qu’une entreprise développe son propre cadre de travail et qu’elle en reste propriétaire.
Attention à ne pas confondre “développement sur-mesure” et “framework maison” !
Le développement sur-mesure est le fait d’avoir votre propre application qui correspond parfaitement à vos besoins. Un framework maison est souvent la propriété d’une entreprise qui peut être utilisée dans plusieurs applications.
La principale raison de l’existence des frameworks maison est l’accélération des développements.
Mais revenons en arrière, d’où vient cette idée ?
Les géants du développement ont opéré il y a quelques années des changements majeurs, également appelés breaking changes, qui ont démotivé les entreprises de les suivre.
Évoquez le cas AngularAngular est un framework de développement JavaScript populaire basé sur TypeScript. JS à un développeur, il saura vous en parler ! Pour résumer, beaucoup de projets avaient été lancés sur ce framework créé par Google qui a tout simplement disparu peu de temps après. Il a fallu tout recommencer.
Idem pour .NET 3.5 qui est passé directement à .NET 4.
C’est à cette époque que les frameworks maison ont émergé, car on n’est jamais mieux servi que par soi même ! Sauf que dans les faits, c’est un peu différent.
L’informatique évolue très vite. Tous les langages ont des mises à jour fréquentes, dont certaines sont majeures. En fonction du langage, cela peut être tous les 2 à 7 ans pour les LTS (long term service).
Le risque avec les frameworks maison : rater des mises à jour du langage et voir apparaître des bugs et de la dette technique qui s’accumule.
Pour en savoir plus sur la dette technique, vous pouvez lire notre article à ce sujet ou écouter notre interview de Fabrice Ubertosi, architecte technique chez CPage.
Votre application est condamnée à utiliser ce même framework maison qui n’est pas modifiable.
Vous pourrez donc difficilement changer de prestataire.
La seule solution : repartir de zéro pour les développements, et réinvestir temps et argent.
Vous pourrez toujours essayer de “bricoler” pour que ça fonctionne, mais ça ne sera pas pérenne.
Pour éviter ça, il faut bien sûr vous appuyer sur des experts techniques.
Même si vous ne l’êtes pas, vous pouvez aussi regarder de votre côté :
Chez AXOPEN, nous utilisons des frameworks officiels ou open source pour éviter ces problématiques et construire des applications durables.
En utilisant un framework standard, le code n’appartiendra pas à l’entreprise qui l’a développé et respectera les standards du marché. Résultat : il n’y aura aucune difficulté à reprendre le projet pour un autre prestataire.
Votre application sur-mesure aura un code de qualité, ce qui signifie du temps et donc un prix, mais qui sera toujours plus faible que de tout reprendre à zéro.
Pour conclure, on vous conseille de bien choisir votre prestataire technique en posant le maximum de questions et en faisant vos propres recherches, même si votre profil n’est pas technique.
Enfin, prévoyez dans l’enveloppe de départ un budget pour réaliser un audit de code source par une entreprise tierce pour vérifier que les standards sont bien respectés, c’est la meilleure manière d’éviter les mauvaises surprises !
Découvrez la planche #18 !
Découvrez la planche #6 !
Dans les précédentes versions de JBoss, il était très facile de récupérer des informations de monitoring via les MBean. Ce biais de récupération disparait dans JBoss 7 au profite du CLI et de la console web de management.