FAQ

Il n’existe pas de réponse universelle à cette question.
Le choix dépend de nombreux paramètres, très variables d’une organisation à l’autre comme le niveau de la dette technique, la dépendance à des ressources clés, la disponibilité des compétences internes, la capacité à piloter un projet structurant, les marges de manœuvre budgétaires ou encore la trajectoire cible du système d’information à moyen terme…
Dans certains cas, la refonte est pertinente. Mais elle n’est ni systématique ni toujours pertinente.
Dans de certaines situations, il est possible, et parfois préférable, de sécuriser, de stabiliser et de moderniser progressivement l’existant afin d’en prolonger la durée de vie dans de bonnes conditions, tout en réduisant les risques immédiats.
Nous préconisons pour cela de commencer par la réalisation d’un état des lieux, avec un audit, qui permet de décider en connaissance de cause si une refonte est nécessaire, partielle ou évitable à court ou moyen terme.
Un scénario de modernisation progressive peut constituer une réponse pertinente et pragmatique, sans exclure pour autant à plus long terme, une éventuelle refonte lorsque les conditions seront réunies.

La couverture du périmètre analysé lors d’un audit dépend vraiment du contexte et des raisons qui motivent son lancement. Il peut avoir vocation à répondre à des questions techniques très précises comme l’identification des causes possibles d’une dégradation progressive des performances ou l’identification de potentielles failles de sécurité dans l’application. Mais il peut aussi être lancé pour répondre à des questions plus larges comme l’identification globale des risques que ce soit en termes de continuité de service, de maintenabilité, voire même de capacité de la solution à répondre aux besoins des métiers et de l’organisation à court ou moyen terme.

C’est pour ça que la phase de cadrage en amont est importante, car c’est elle qui va permettre de définir précisément les axes à analyser (technique, gestion de projet, gouvernance, usage & expérience utilisateur…), les parties prenantes et d’éventuels points spécifiques à explorer.
Quel que soit le périmètre, la trame du rapport de restitution reste toujours la même : le rapport présente les constats clés de l’audit, l’analyse des risques associés, les scénarios possibles d’évolution et des recommandations priorisées et chiffrées pour faciliter et sécuriser la prise de décision.

Oui. Nous proposons ce que nous appelons un diagnostic flash, conçu pour fournir, dans un délai resserré (environ une semaine), une vision globale et objective de l’état de votre application.

Ce diagnostic permet d’évaluer : la qualité et la robustesse du code et de l’architecture, les pratiques projet, l’expérience utilisateur.
Il est complété par : l’identification des 5 principaux risques, classés par niveau de criticité et de probabilité, une liste d’actions recommandées, assorties d’une estimation de charge et de complexité.

Sans être exhaustif ni trop approfondi, le diagnostic flash est particulièrement efficace pour décider vite et bien, sur la base d’éléments concrets et objectivés.
Il peut notamment être réalisé en amont d’un passage en TMA, afin de cibler les actions à fort retour sur investissement et de traiter en priorité les besoins les plus urgents.

Non. La réalisation de l’audit n’implique aucun engagement pour la suite.
Vous restez totalement libre de mettre en œuvre tout ou partie des préconisations, que ce soit avec vos équipes internes ou avec un autre prestataire.
Dans la pratique, certains clients choisissent de nous confier la mise en œuvre de certaines recommandations ou un accompagnement complémentaire (coaching technique, aide à la structuration de la démarche projet ou de la gouvernance).
Cela reste toutefois une option, jamais une obligation. Vous demeurez pleinement souverain dans vos décisions quant aux suites à donner à l’audit.

La définition de l’architecture cible doit être alignée avec les objectifs métiers et stratégiques, tout en respectant les contraintes opérationnelles, budgétaires et organisationnelles de l’entreprise.

Elle intègre des éléments concrets d’usage et d’exploitation, comme la nécessité de fonctionnement en mode déconnecté pour certaines fonctionnalités, les attentes en matière de supervision, de monitoring et d’observabilité, en particulier sur les composants critiques, ainsi que la mise en place d’une chaîne DevOps et d’intégration continue adaptée au contexte.

Les enjeux de sécurité, de conformité et de souveraineté sont également pris en compte dès la conception (gestion des accès, traçabilité, protection des données). Enfin, l’architecture cible est définie en tenant compte des compétences présentes au sein de l’organisation : si la maintenance doit être assurée en interne, il est essentiel que les équipes puissent comprendre, s’approprier et faire évoluer l’architecture mise en place dans la durée.

L’objectif est de définir une architecture pragmatique, évolutive et soutenable, capable d’accompagner une transition progressive sans mise en risque de l’activité.

Il n’existe pas de réponse unique : le plan de transition dépend fortement du contexte de chaque organisation, de son métier, de son existant, de ses contraintes et de sa maturité.

En revanche, l’expérience montre que l’implication de certaines parties prenantes constitue un facteur clé de succès, à adapter au cas par cas.
L’implication des métiers ou de leurs représentants est essentielle pour identifier les fonctionnalités clés à conserver, celles à faire évoluer, celles à ajouter ou à supprimer, et pour disposer d’une vision claire de la couverture fonctionnelle cible ainsi que des évolutions attendues.
La DSI joue un rôle central dans la définition et la validation de l’architecture cible, des principes de transition, ainsi que des attentes en matière d’exploitation, de sécurité et de maintenabilité.
Lorsque cela est possible, l’implication de la direction ou du COMEX permet de valider le scénario global de transition, les ordres de grandeur budgétaires et de disposer d’un sponsor au plus haut niveau pour accompagner le changement dans la durée.
Enfin, selon les choix retenus, les équipes RH peuvent également être associées afin d’anticiper les besoins en montée en compétences, en formation ou en recrutement, notamment si la maintenance de la solution cible doit être assurée en interne.

L’objectif n’est pas de mobiliser tout le monde en permanence, mais de faire intervenir les bonnes personnes au bon moment, afin de co-construire une trajectoire réaliste, partagée et durable.

Oui, totalement. La définition du plan de transition est indépendante de la phase de mise en œuvre.

Notre rôle est de vous aider à construire une trajectoire claire, réaliste et sécurisée, en toute transparence. Une fois le plan défini, vous restez libres de choisir les partenaires avec lesquels vous souhaitez réaliser les travaux.

Si vous le souhaitez, nous pouvons également vous accompagner dans la phase de mise en œuvre, mais cela ne constitue en aucun cas une obligation.
Quel que soit le choix retenu, il est en revanche essentiel que l’équipe en charge de la transition dispose à la fois d’une bonne connaissance de l’existant WINDEV et d’une maîtrise de la stack et de l’architecture cible. Cette double compétence est clé pour sécuriser la coexistence entre l’ancien et le nouveau système, garantir la continuité de service et éviter de recréer de nouvelles fragilités techniques.

L’objectif reste de vous donner les clés pour décider et agir en toute maîtrise, avec des partenaires adaptés à votre contexte et à votre trajectoire.

Le choix entre un mode projet et un renfort en assistance technique dépend principalement de votre niveau de maturité, de vos contraintes internes et du degré de structuration du besoin.

Privilégiez un accompagnement en mode projet si : 

• Le périmètre fonctionnel est clairement identifié 
• Vous souhaitez externaliser le pilotage et la responsabilité 
• Vous avez besoin d’un engagement fort sur les délais et les livrables 
• Vous disposez de peu de capacité interne pour cadrer ou conduire le projet

Le mode projet permet de sécuriser l’exécution et de confier la responsabilité à un partenaire engagé sur les résultats.

Privilégiez un renfort en mode assistance technique si : 

• Le besoin évolue dans le temps ou n’est pas totalement figé
• Vous souhaitez garder la maîtrise directe du pilotage 
• Vos équipes internes sont structurées mais manquent de capacité
• Vous avez besoin de renfort rapide et flexible 

L’assistance technique permet de renforcer vos équipes sans rigidité, en restant au plus près de vos priorités opérationnelles.

Et si vous hésitez ? 
Dans de nombreux cas, une approche hybride est la plus pertinente :

• cadrage ou socle en mode projet
• puis renfort d’équipe pour accompagner la montée en charge ou les évolutions

Chez ISIMEDIA, nous vous aidons à choisir le mode d’intervention le plus adapté à votre contexte, sans parti pris, et pouvons faire évoluer le dispositif en cours de route si nécessaire.

Chez ISIMEDIA, l’éco-conception n’est pas une contrainte supplémentaire. C’est une manière pragmatique de concevoir des applications : en allant à l’essentiel, en privilégiant la valeur réelle et en limitant la complexité inutile.

Dans de nombreux projets logiciels, une part importante des fonctionnalités développées est finalement peu ou pas utilisée. Cette sur-production génère de la dette technique, alourdit la maintenance et augmente durablement les coûts de développement et d’exploitation.

Notre approche consiste à recentrer le projet sur ce qui crée réellement de la valeur pour les utilisateurs et pour l’organisation. Moins de fonctionnalités superflues, c’est aussi moins de code, moins de risques, moins de vulnérabilités, moins de maintenance et une meilleure capacité d’évolution dans le temps.

L’éco-conception devient ainsi un levier de performance globale : applications plus simples, plus robustes, plus rapides, mais aussi plus souveraines et durables. Elle permet de bâtir un patrimoine applicatif maîtrisé, capable d’évoluer sans subir une inflation continue des coûts et de la complexité.

Notre positionnement repose historiquement sur une indépendance assumée vis-à-vis des éditeurs, dont PC SOFT. Nous avons fait le choix de proposer à nos clients une approche multi-technologies, afin de répondre à leurs enjeux métiers et stratégiques sans dépendre d’un écosystème unique.
Ce positionnement est compatible avec notre expertise reconnue des technologies PC SOFT, tout en garantissant une liberté de conseil et d’action dans les trajectoires de transformation que nous proposons et accompagnons.

Les deux ne sont absolument pas incompatibles. Pourquoi les opposer ?


WINDEV est une technologie mature, productive et fiable, dont les qualités historiques demeurent pleinement pertinentes pour de nombreuses applications desktop internes. Lorsqu’un patrimoine applicatif PC SOFT existe ou que les équipes maîtrisent déjà la technologie, ce choix est non seulement cohérent, mais souvent rationnel.

Pour autant, nous accompagnons également de nombreux clients qui font le choix de faire évoluer leurs applications vers le web ou vers des architectures cloud ready, et qui souhaitent, dans ce cadre, s’orienter vers d’autres technologies que PC SOFT. Ces trajectoires répondent à des enjeux clairement identifiés : évolution des usages, ouverture des systèmes, besoins de scalabilité ou d’interopérabilité…

ISIMEDIA dispose du recul, des compétences et de l’expérience nécessaires pour accompagner ces transformations de manière progressive et maîtrisée, en capitalisant sur l’existant plutôt qu’en repartant de zéro. C’est, dans bien des cas, la stratégie la plus efficace et la plus sécurisante.

Notre rôle n’est pas de promouvoir une technologie plutôt qu’une autre, mais d’apporter un éclairage expert et pragmatique, au service de décisions durables, alignées avec les enjeux métiers et techniques de nos clients. La trajectoire technologique reste toujours entre leurs mains : ils demeurent pleinement souverains dans leurs choix.

L’IA ne permet pas de porter automatiquement une application WINDEV de bout en bout, et ce n’est ni réaliste ni souhaitable. En revanche, elle constitue un levier puissant pour accélérer et sécuriser une transition, lorsqu’elle est utilisée de manière maîtrisée.
Concrètement, l’IA nous aide à analyser l’existant, à identifier les règles métiers, les dépendances fonctionnelles et techniques, ainsi qu’à qualifier les zones à risque. Pour cela, nous nous appuyons sur un socle interne issu de plusieurs mois de travaux de R&D, conçu pour produire des contenus fiables et réellement exploitables, tout en préservant la confidentialité des données et des codes sources traités.
L’IA peut également assister la production de code sur l’architecture cible, toujours sous le contrôle des équipes projet, comme pour les phases d’analyse.
L’ensemble du processus reste entièrement piloté par des experts : les choix d’architecture, les arbitrages fonctionnels et les validations sont réalisés par nos équipes, l’IA agissant comme un outil d’aide, et non comme un automatisme aveugle.
Cette combinaison entre expertise humaine et IA permet d’éviter les réécritures inutiles, de réduire les délais, et de sécuriser la qualité du portage, tout en conservant la logique métier existante.

Une simple migration technique consiste à porter une application à l’identique vers un nouvel environnement. Notre accompagnement va bien au-delà.
Nous abordons la transition comme une opportunité de repenser et d’améliorer l’existant, en associant étroitement les métiers pour décider de ce que l’on conserve, simplifie, supprime ou fait évoluer. Les applications de 10 à 15 ans portent souvent une dette fonctionnelle importante ; la transition permet de la réduire.
Dans une logique d’éco-conception, nous conservons et renforçons les fonctionnalités à forte valeur métier, tout en éliminant le superflu et les usages obsolètes. Cette démarche simplifie les applications, favorise leur adoption et contribue à maîtriser les coûts et la complexité de la transition.
Enfin, notre approche s’inscrit dans la stratégie globale de l’organisation : usages actuels et futurs, architecture cible, exigences de scalabilité et de volumétrie des données.
C’est cette combinaison entre vision métier, réflexion stratégique et expertise technique qui différencie notre accompagnement d’une simple migration.