QlikView reste exploitable tant que votre version est supportée, mais le calendrier de l’éditeur réduit fortement la marge de manœuvre. La version 12.90 sort du support le 31 octobre 2026, tandis que QlikView 12.100 est supporté jusqu’au 30 septembre 2027. Une migration vers Qlik Sense doit donc commencer par l’usage réel, les règles de calcul et la recette.
En bref.
- La fin de vie ne signifie pas l’arrêt immédiat des applications QlikView, mais la disparition du support éditeur et des correctifs sur la version concernée.
- Qlik Sense ne reprend pas automatiquement les documents QlikView, leurs objets graphiques, leurs macros et leurs règles de présentation.
- Les scripts de chargement peuvent parfois être réutilisés, mais ils doivent être relus dès qu’ils dépendent de variables, de chemins de fichiers ou de composants propres à QlikView.
- Un inventaire sur douze mois d’usage permet de distinguer les tableaux de bord à reconstruire de ceux qui doivent être retirés.
- La recette doit comparer des périmètres, des mesures et des écarts acceptés, sans promettre une identité automatique entre l’ancien et le nouvel outil décisionnel.
Ce contenu vise les responsables BI, DSI et chefs de projet qui maintiennent un parc QlikView en environnement géré par l’entreprise. Il traite de la maintenance, des différences avec Qlik Sense et de la migration des applications décisionnelles, mais pas de la négociation contractuelle avec Qlik ni des questions de protection des données personnelles.
Quelle date de fin de vie QlikView s’applique à votre version
La date utile n’est pas celle de l’installation initiale de QlikView, mais celle de la version exacte encore exécutée sur le serveur. Un parc qui utilise QlikView 12.90 et un parc passé à QlikView 12.100 ne portent pas le même risque de maintenance. Qlik publie un tableau de cycle de vie par release, associé à sa politique de gestion des versions des produits on-premise.
Le relevé effectué sur la page officielle QlikView Product Lifecycle, mise à jour le 10 juillet 2026, indique que QlikView 12.90, publiée le 21 mai 2024, atteint sa date EOS le 31 octobre 2026. La release QlikView 12.100, publiée le 23 septembre 2025, reste couverte jusqu’au 30 septembre 2027. Ces échéances doivent être revérifiées chaque trimestre, car elles relèvent de la politique de maintenance de l’éditeur.
| Version QlikView | Date de publication | Date de fin de support | Conséquence de pilotage |
|---|---|---|---|
| 12.100 | 23 septembre 2025 | 30 septembre 2027 | Le parc dispose d’un délai pour mesurer les usages et organiser une migration sélective. |
| 12.90 | 21 mai 2024 | 31 octobre 2026 | Le budget, le périmètre et la stratégie de recette doivent être arbitrés avant l’échéance. |
| 12.80 | 23 mai 2023 | 31 octobre 2025 | La version est déjà hors support au regard du relevé du 10 juillet 2026. |
| 12.70 | 10 mai 2022 | 10 mai 2024 | Le maintien expose le socle à une absence de support éditeur sur incident. |
| 12.60 | 25 mai 2021 | 25 mai 2023 | Une mise à niveau ou une sortie du produit ne doit plus être différée sans arbitrage écrit. |
Source du tableau, cycle de vie QlikView publié par Qlik et consulté le 10 juillet 2026. Le tableau ne préjuge pas des conditions particulières de votre contrat de support. Il donne la date affichée par l’éditeur pour chaque release, pas une garantie de support sur vos extensions, vos macros ou vos connecteurs tiers.
Rester sur une version hors support ne fait pas disparaître vos tableaux de bord le lendemain. Les documents QVW continuent normalement de s’ouvrir si l’infrastructure demeure disponible. Le problème survient lorsqu’un incident exige un correctif, lorsqu’une mise à jour du système d’exploitation modifie un comportement attendu ou lorsqu’un audit demande la preuve d’un support maintenu. Le risque est opérationnel avant d’être fonctionnel.
La version 12.100 peut justifier une période d’attente si votre usage est stable, si les applications sont documentées et si les composants périphériques restent maintenus. L’arbitrage change pour QlikView 12.90. À quelques mois de l’échéance d’octobre 2026, lancer une migration complète sans avoir trié le parc conduit souvent à reprendre des applications dont personne ne consulte plus les indicateurs.
Pourquoi la fin du support ne se traite pas comme une simple mise à jour
Une mise à jour de release conserve la logique applicative. Une migration vers Qlik Sense remet en cause le mode de publication, les objets de restitution, les droits et parfois les habitudes de navigation. Le script de chargement constitue seulement une partie de l’application. Les expressions dans les graphiques, les variables, les favoris, les déclencheurs et les macros peuvent porter des règles de gestion qu’aucun dossier projet ne décrit.
La première pièce à produire est donc une cartographie. Elle relie chaque document QVW à son propriétaire métier, à ses utilisateurs actifs, à sa fréquence d’ouverture, à ses sources et à ses mesures sensibles. Sans cette liste, le calendrier de fin de vie devient un motif de panique plutôt qu’un critère de priorisation. La prochaine étape consiste à vérifier quelles applications méritent réellement une reprise dans Qlik Sense.
Quelles différences entre QlikView et Qlik Sense changent réellement la migration
QlikView et Qlik Sense partagent le moteur associatif de Qlik, mais ils ne répondent pas au même mode de construction des applications. QlikView repose historiquement sur des documents QVW conçus comme des applications de restitution, souvent bâties par une équipe BI centrale. Qlik Sense organise les contenus autour d’applications, de feuilles, d’objets et d’espaces de publication, avec une place plus visible donnée à la création guidée et à l’exploration par les utilisateurs autorisés.
La différence qui pèse le plus sur une migration concerne les objets graphiques. Une jauge, un tableau croisé, une zone de texte dynamique ou un conteneur QlikView n’a pas toujours un équivalent de reprise automatique dans Qlik Sense. L’équipe projet doit distinguer la mesure à conserver de la forme historique du tableau de bord. Conserver chaque pixel coûte cher et ne protège pas forcément la compréhension métier.
Les documents QlikView utilisent aussi des mécanismes qui demandent une revue précise. Les macros, les actions déclenchées par un bouton, les extensions anciennes et certaines automatisations d’export ne se transposent pas mécaniquement. Une macro peut sembler secondaire parce qu’elle n’apparaît pas dans un graphique. Pourtant, elle peut alimenter un fichier de contrôle mensuel ou conditionner une diffusion à un groupe de destinataires.
Qlik indique dans son aide consacrée à la comparaison entre QlikView et Qlik Sense que Qlik Sense propose une approche plus moderne et intégrable, tout en orientant les organisations qui envisagent une sortie de QlikView vers des ressources de planification. Cette documentation doit être lue avec la version de votre produit, car le périmètre des fonctionnalités et des connecteurs évolue d’une release à l’autre.
Les scripts de chargement ne constituent pas un passeport de migration
Les scripts QlikView représentent souvent la partie la plus visible de l’analyse de données. Ils chargent les fichiers, interrogent les bases, créent des tables résidentes, définissent des variables et construisent le modèle associatif. Leur syntaxe peut être proche de celle attendue dans Qlik Sense, ce qui crée une impression de continuité. Cette continuité est réelle dans certains cas, mais elle n’exonère pas d’une recette.
Un script qui lit un répertoire local, un lecteur réseau ou un fichier QVD dépend d’un chemin technique et d’un compte de service. Dans Qlik Sense, le mode de connexion, les droits et les emplacements publiés peuvent être différents. Les variables de chemin, les fichiers de paramètres et les tâches de rechargement doivent être testés séparément du résultat affiché dans les tableaux de bord.
Le modèle de sécurité demande le même niveau d’attention. Dans QlikView, une réduction de données peut être portée par une table Section Access et des conventions d’identifiants très anciennes. Dans Qlik Sense, la publication dans les espaces, l’authentification et les règles de sécurité doivent être alignées sur les droits attendus. Un tableau de bord correct pour l’administrateur peut être incomplet ou trop large pour un responsable opérationnel.
Les différences les plus coûteuses ne sont donc pas toujours visibles à l’écran. Elles se trouvent dans les expressions, les droits, les déclenchements et les dépendances de chargement. Avant de choisir une cible, il faut mesurer l’usage réel de l’existant plutôt que de traiter tous les QVW comme des actifs de même valeur.
Comment déterminer quels tableaux de bord QlikView doivent être migrés
Le volume de documents QVW ne mesure pas le volume de travail utile. Un répertoire peut contenir cent applications, mais une part significative correspond parfois à des essais, à des copies datées ou à des restitutions remplacées par un autre support. Le tri doit s’appuyer sur les traces d’usage, les propriétaires métier et les échéances de reporting. Une liste de fichiers ne suffit pas.
Les logs d’audit sur douze mois donnent une première lecture. Ils permettent de repérer les applications ouvertes chaque jour, celles utilisées à la clôture mensuelle et celles qui ne sont consultées par personne. Ils ne doivent pas être interprétés sans précaution. Une rétention de quatre-vingt-dix jours masque les rapports trimestriels ou annuels. Un document diffusé en PDF peut rester peu ouvert dans l’interface tout en alimentant une décision récurrente.
Le contrôle doit donc combiner les données d’usage et une validation métier formelle. Pour chaque application, le responsable BI peut demander quelle décision dépend du tableau de bord, quel service l’utilise, quelle période de conservation est requise et si une restitution équivalente existe déjà. Une réponse vague ne justifie pas une reprise. En revanche, un indicateur de marge présenté chaque mois à la direction financière mérite un dossier de recette complet.
Une classification en quatre décisions réduit la charge inutile
La cartographie peut classer chaque document dans quatre catégories. La première regroupe les applications à reconstruire parce qu’elles sont actives, sensibles et structurantes. La deuxième couvre les applications à reprendre avec une simplification de l’interface. La troisième rassemble les restitutions à consolider dans une application déjà existante. La quatrième regroupe les documents à retirer après validation de leur propriétaire métier.
- Une application ouverte chaque semaine par plusieurs équipes et portant des mesures de clôture doit être reconstruite avec une recette sur des périodes historiques définies.
- Un document utilisé ponctuellement pour explorer un détail peut être repris avec moins d’objets, à condition que les sélections et les exports réellement utilisés soient conservés.
- Deux tableaux de bord qui présentent la même mesure avec des filtres proches peuvent être regroupés après validation des règles de calcul et des populations concernées.
- Un QVW sans ouverture sur douze mois, sans diffusion identifiée et sans propriétaire disponible doit être proposé au retrait, non migré par défaut.
Cette classification protège le budget contre un réflexe coûteux, la reprise à l’identique. Un parc de 80 documents dont 40 ne sont plus consultés ne justifie pas la même stratégie qu’un parc de 400 documents actifs avec des règles de gestion réparties dans les expressions. Dans le premier cas, la reconstruction sélective est souvent plus défendable. Dans le second, la reprise contrôlée peut préserver des calculs métier qu’il serait risqué de redécouvrir sous pression.
Le système décisionnel ne se limite pas à la couche de visualisation. Les dictionnaires, les sources, les calendriers, les dimensions et les règles de qualification influencent directement les résultats affichés. La mise à jour d’un dictionnaire de données pour la migration évite de déplacer des expressions dont personne ne sait plus expliquer l’origine.
Un inventaire utile contient au minimum l’identifiant du document, la dernière ouverture connue, le propriétaire métier, la source principale, le nombre d’onglets, les mesures sensibles, les mécanismes de sécurité et la décision retenue. Cette base devient le registre de périmètre du projet. Sans elle, les demandes tardives réintroduisent des applications hors budget au moment où la recette devrait déjà être stabilisée.
La décision de retrait ne doit pas être assimilée à une perte de service. Elle consiste à demander une confirmation explicite que le besoin n’existe plus ou qu’il est couvert ailleurs. Ce travail ouvre ensuite un sujet plus exigeant, celui de la charge réelle de migration pour les applications retenues.
Comment chiffrer une migration QlikView vers Qlik Sense sans sous-estimer la recette
Un chiffrage sérieux sépare l’inventaire, la reprise technique, la reconstruction des objets, la validation fonctionnelle, la recette des chiffres, la reprise des droits et l’accompagnement des utilisateurs. Présenter un nombre global de jours sans détailler ces postes rend le budget impossible à défendre. Les ratios ci-dessous sont des hypothèses de préparation, pas un tarif ni une promesse de durée.
Un exemple permet de rendre le calcul vérifiable. Considérons un parc de 120 documents QVW. L’inventaire sur les logs et les entretiens métier conduit à retirer 35 documents, à consolider 15 documents dans des applications existantes et à retenir 70 applications pour une migration. Parmi elles, 40 sont classées comme peu complexes, 20 comme intermédiaires et 10 comme complexes, selon le nombre d’onglets, les règles de sécurité, les sources et les expressions.
Pour cet exemple, la reprise fonctionnelle et technique est estimée à 16 heures par application peu complexe, 40 heures par application intermédiaire et 80 heures par application complexe. Ces ratios sont construits pour un dossier comportant lecture des scripts, reconstruction des feuilles, contrôles de chargement et tests unitaires. Ils excluent la recette métier complète, la formation, les licences, la remédiation des sources et la négociation contractuelle.
| Type d’application retenue | Volume | Ratio de reprise | Charge calculée |
|---|---|---|---|
| Application peu complexe | 40 | 16 heures | 640 heures |
| Application intermédiaire | 20 | 40 heures | 800 heures |
| Application complexe | 10 | 80 heures | 800 heures |
| Total de reprise avant recette | 70 | Selon les hypothèses ci-dessus | 2 240 heures |
Ce calcul aboutit à 2 240 heures pour la seule reprise des applications retenues. Si le projet ajoute une recette métier représentant 30 % de cette charge, l’enveloppe de recette atteint 672 heures. Le total passe alors à 2 912 heures, avant formation, conduite du changement, traitement des anomalies de source et gestion détaillée des habilitations. L’écart entre 2 240 et 2 912 heures montre pourquoi la recette ne doit jamais être cachée dans une ligne générique de projet.
Les écarts de chiffres doivent être attendus, mesurés et acceptés
Une migration ne garantit pas que les chiffres seront identiques à l’ancien socle. Les différences peuvent provenir d’une date de rafraîchissement, d’un filtre implicite, d’une jointure, d’un arrondi, d’une table de sécurité ou d’une règle de sélection. L’objectif n’est pas de nier ces écarts. Il est de les identifier, de les qualifier et de décider lesquels sont acceptables.
Pour une mesure de chiffre d’affaires, une recette robuste compare un même périmètre de date, une même population de clients, un même statut de commande et une même devise. Le résultat doit être conservé dans un fichier de comparaison signé par le métier. Si un écart apparaît, il faut documenter sa cause avant d’autoriser la bascule. Une différence de 0,4 % peut être acceptable pour une variation d’arrondi sur une restitution exploratoire, mais elle ne l’est pas nécessairement pour une clôture financière.
Le protocole peut s’inspirer d’une démarche décrite dans ce protocole de migration BI et de réconciliation. Il sépare la conformité du chargement, la validité des mesures, la sécurité d’accès et l’acceptation métier. Ces quatre contrôles ne portent pas le même risque et ne doivent pas être validés par la même personne.
Un double run limité dans le temps permet de comparer l’ancien QlikView et le nouveau Qlik Sense sur plusieurs cycles métier. Il ne doit pas durer indéfiniment, car deux applications vivantes doublent les corrections et entretiennent l’ambiguïté sur la source de référence. Sa durée dépend de la fréquence du reporting. Une clôture mensuelle exige au minimum un cycle complet, parfois davantage lorsque des traitements trimestriels conditionnent les indicateurs.
La charge de migration devient donc défendable lorsque chaque ratio est rattaché à un type d’application et que chaque poste exclu est visible. Le choix de l’ordre de bascule peut alors être construit sur le risque métier, plutôt que sur la seule ancienneté technique.
Dans quel ordre organiser la migration QlikView vers Qlik Sense
L’ordre de migration ne doit pas suivre l’alphabet des applications ni la date de création des documents. Il doit rapprocher trois informations, l’échéance de support de la version QlikView, le niveau d’usage du tableau de bord et la criticité des règles métier. Une application complexe, très utilisée et peu documentée mérite un cadrage précoce. Elle ne doit pas nécessairement être la première à basculer en production.
Les premières vagues servent à éprouver la méthode sur des applications représentatives mais maîtrisables. Elles doivent comporter un script de chargement réel, des droits d’accès, plusieurs feuilles et une mesure sensible, sans être le seul tableau de bord utilisé pour une clôture. Cette approche permet de tester les conventions de développement Qlik Sense, la publication, les validations et la production de preuves de recette.
Le lot suivant peut couvrir des tableaux de bord à forte utilisation, une fois que le modèle de sécurité, les règles de nommage et le protocole de validation ont été stabilisés. Les applications à faible usage ou à propriétaire absent doivent rester hors de la première vague. Elles créent du volume administratif, mais apportent peu de retour sur le risque de bascule.
Un déroulement en cinq étapes rend les arbitrages visibles
- Établissez l’inventaire des documents QVW, des tâches de rechargement, des sources, des propriétaires et des utilisateurs sur une période de douze mois.
- Classez les applications entre retrait, consolidation, reconstruction et reprise, puis faites valider cette décision par les responsables métier concernés.
- Analysez les scripts, les variables, la Section Access, les macros, les extensions et les expressions des applications retenues avant de fixer la charge.
- Construisez les applications Qlik Sense par vagues, avec des jeux de tests identiques, des périmètres documentés et une traçabilité des anomalies.
- Organisez le double run, obtenez l’acceptation métier des écarts expliqués, puis planifiez l’arrêt contrôlé du document QlikView remplacé.
La modernisation ne consiste pas à produire une copie plus récente d’un écran historique. Elle consiste à décider ce qui doit survivre, ce qui doit être simplifié et ce qui doit être retiré. Un projet qui évite cette décision déplace le coût de maintenance de QlikView vers Qlik Sense sans réduire la dette décisionnelle.
Le pilotage doit aussi intégrer la communication vers les utilisateurs. Ceux-ci doivent connaître la date de disponibilité du nouveau tableau de bord, la période pendant laquelle l’ancien reste consultable, les écarts documentés et le canal de remontée des anomalies. Les équipes métier ne valident pas un outil décisionnel parce qu’il est techniquement publié. Elles le valident lorsqu’elles peuvent retrouver leurs décisions et comprendre les différences constatées.
Les parcours de migration partagent plusieurs sujets avec d’autres socles décisionnels, notamment la cartographie des usages et la comparaison des indicateurs. Le coût d’un chantier dépend toutefois du produit source, des règles de sécurité et du volume d’objets à reconstruire. Une comparaison avec le coût de migration de BusinessObjects vers Power BI peut aider à distinguer la charge de reprise des rapports de la charge propre au modèle sémantique, sans appliquer mécaniquement les mêmes ratios à QlikView.
Avant toute validation budgétaire, extrayez les logs disponibles, vérifiez leur durée de conservation et reliez chaque document QVW à un propriétaire et à une décision métier. Cette action détermine le périmètre réel, donc le calendrier et la charge du projet.
QlikView est-il déjà en fin de vie ?
La réponse dépend de la version utilisée. Selon le cycle de vie Qlik relevé le 10 juillet 2026, QlikView 12.90 atteint sa fin de support le 31 octobre 2026, tandis que QlikView 12.100 reste supporté jusqu’au 30 septembre 2027. Les versions antérieures à 12.90 sont déjà hors support selon le tableau éditeur.
Peut-on convertir automatiquement un document QlikView en application Qlik Sense ?
La reprise peut réutiliser une partie des scripts de chargement selon leur contenu, mais les objets graphiques, macros, extensions, droits et mécanismes de diffusion exigent une analyse spécifique. Une conversion ne dispense pas de recette fonctionnelle et de validation métier.
Quelle est la principale différence entre QlikView et Qlik Sense ?
QlikView est principalement organisé autour de documents QVW conçus comme des applications de restitution, alors que Qlik Sense structure les usages autour d’applications, de feuilles, d’objets et d’espaces de publication. Cette différence affecte les tableaux de bord, la sécurité et les modalités de mise à disposition.
Faut-il migrer tous les tableaux de bord QlikView ?
Non. Les documents non consultés, redondants ou sans propriétaire métier identifié doivent être proposés au retrait ou à la consolidation. L’inventaire sur douze mois, complété par une validation métier, permet d’éviter de financer la reprise d’applications sans usage démontré.
Comment prouver que les chiffres Qlik Sense sont acceptables après migration ?
Le projet doit comparer des périmètres identiques, documenter les mesures, tracer les écarts et obtenir une acceptation métier. Le double run entre QlikView et Qlik Sense sert à expliquer les différences, non à promettre une identité automatique des résultats.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
