AVIS D'INFORMATIONS COMPLÉMENTAIRES, AVIS D'INFORMATIONS SUR UNE PROCÉDURE INCOMPLÈTE OU AVIS RECTIFICATIF

Transcription

1 1/ 7 BE001 04/06/ Numéro BDA: Formulaire type 14 - FR Bulletin des Adjudications Publication du Service Fédéral e-procurement SPF P&O - 51, rue de la Loi B-1040 Bruxelles e.proc@publicprocurement.be AVIS D'INFORMATIONS COMPLÉMENTAIRES, AVIS D'INFORMATIONS SUR UNE PROCÉDURE INCOMPLÈTE OU AVIS RECTIFICATIF Rappel: si la rectification ou l'ajout d'informations entraîne une modification substantielle des conditions indiquées dans l'avis de marché original susceptible d'influer sur le principe de l'égalité de traitement et les objectifs de la mise en concurrence, il sera alors nécessaire de proroger les dates limites initialement prévues. SECTION I: POUVOIR ADJUDICATEUR I.1) NOM, ADRESSES ET POINT(S) DE CONTACT Nom officiel: IMIO Code d'identification national: Adresse postale: Avenue Thomas Edison, 2 Localité/Ville: Mons Code postal: 7000 Pays: Belgique Point(s) de contact: Madame Véronique Bouchez Téléphone: À l attention de: Courrier électronique ( ): Adresse(s) internet (le cas échéant) v.bouchez@imio.be Fax: Adresse générale du pouvoir adjudicateur (URL): Adresse du profil d acheteur (URL): Accès électronique à l'information (URL): Soumission des offres et des demandes de participation par voie électronique (URL): I.2) TYPE D'ORGANISME ACHETEUR Pouvoir adjudicateur (dans le cas d'un marché couvert par la Directive 2004/18/CE) Entité adjudicatrice (dans le cas d'un marché couvert par la Directive 2004/17/CE "Secteurs spéciaux")

2 2/ 7 BE001 04/06/ Numéro BDA: Formulaire type 14 - FR SECTION II: OBJET DU MARCHÉ II.1) DESCRIPTION II.1.1) Intitulé attribué au marché par le pouvoir adjudicateur (tel qu'indiqué dans l'avis original) II.1.2) Description succincte (tel qu'indiqué dans l'avis original) Contexte : L'Intercommunale IMIO est opérationnelle depuis le 1er janvier Elle a pour objectif de promouvoir et de coordonner la mutualisation de solutions métiers, de produits et services pour les pouvoirs locaux et est articulée autour de trois activités principales: - Produire des logiciels Open source répondant aux besoins des pouvoirs locaux. Le modèle Open source permet à IMIO d'avoir la maîtrise des outils et d'avoir le choix du prestataire pour la réalisation de développements. Une partie des développements peut aussi être assurée en interne, ce qui garantit une plus grande autonomie d'action ; - Acheter des solutions propriétaires en centrale d'achat pour permettre aux communes de bénéficier de solutions du marché à moindre coût et offrir un service d'accompagnement à leur utilisation et leur évolution ; - Formaliser les processus de travail des pouvoirs locaux (organisationnel). La philosophie proposée reste celle de la mutualisation dans la logique «bottom-up» et efforts partagés pour réduire les coûts pour les membres, tout en produisant des solutions mieux adaptées aux réalités des pouvoirs locaux puisque ce sont eux qui les produisent ou les font produire. Objet : Le lot 1 a pour but de dématérialiser des documents de différents types en prenant en compte les standards en matière de capture documentaire. Le lot 2 a pour but de définir un contrat cadre qui permet de mettre en oeuvre une infrastructure d'extraction automatisée des factures dans deux environnements différents : l'infrastructure locale du client finale et l'infrastructure mutualisée d'imio Ces contrats cadre permettront aux adhérents d'imio (CF. annexe C) d'utiliser la centrale d'achat pour commander ces fournitures, licences et services. Une mise à jour régulière de la liste des adhérents sera communiquée au fournisseur sélectionné. Phase type - FRA II.1.3) Classification CPV (vocabulaire commun pour les marchés publics) (tel qu'indiqué dans l'avis original) Descripteur principal Objet principal Objet(s) supplémentaire(s) Descripteur supplémentaire (le cas échéant)

3 3/ 7 BE001 04/06/ Numéro BDA: Formulaire type 14 - FR SECTION IV: PROCÉDURE IV.1) TYPE DE PROCÉDURE IV.1.1) Type de procédure (tel qu'indiqué dans l'avis original) Ouverte Restreinte Restreinte accélérée Négociée Négociée accélérée Dialogue compétitif IV.2) RENSEIGNEMENTS D ORDRE ADMINISTRATIF IV.2.1) Numéro de référence attribué au dossier par le pouvoir adjudicateur/l'entité adjudicatrice (tel qu'indiqué dans l'avis original, le cas échéant) IMIO-PPP0QF-25/001/ /AOG/006/2013-F02_0 IV.2.2) Référence de l'avis (pour les avis envoyés électroniquement) (si elle est connue) Avis original envoyé par: SIMAP OJS esender Login: Référence de l'avis: BE (année et numéro de document) IV.2.3) Avis auquel se réfère la présente publication (le cas échéant) Numéro d avis au JO: 2013/S du 28/05/2013(jj/mm/aaaa) Date d envoi du présent avis: 23/05/2013 (jj/mm/aaaa)

4 4/ 7 BE001 04/06/ Numéro BDA: Formulaire type 14 - FR SECTION VI: RENSEIGNEMENTS COMPLÉMENTAIRES VI.1) L'AVIS IMPLIQUE (le cas échéant; cocher autant de cases que nécessaire) Procédure incomplète Rectification Informations complémentaires VI.3) INFORMATIONS À RECTIFIER OU À AJOUTER (le cas échéant; pour préciser l'endroit où se trouve le texte ou les dates à rectifier ou à ajouter, veuillez toujours indiquer les numéros de section et de paragraphe concernés de l'avis original) VI.3.1) Modification des informations originales ou publication sur le TED non conforme. Modification des informations originales fournies par le pouvoir adjudicateur Publication sur le TED non conforme aux informations originales fournies par le pouvoir adjudicateur Dans les deux VI.3.2) Avis ou dossier d'appel d'offres correspondant Dans l'avis original Dans le dossier d'appel d'offres correspondant (pour de plus amples informations, veuillez vous référer au dossier d'appel d'offres correspondant) Dans les deux (pour de plus amples informations, veuillez vous référer au dossier d'appel d'offres correspondant) VI.3.6) Texte à ajouter dans l'avis original (le cas échéant) VI.4) AUTRES INFORMATIONS COMPLÉMENTAIRES (le cas échéant) Projet de dématérialisation de documents Réponse aux questions Question 1 (p15) : Est-ce que le délai de 50 jours est compté à partir de la date de réception provisoire ou bien à partir de la date de réception définitive? Réponse Q1 : le délai de 50 jours est compté à partir de la date de la réception de la facture émise en bonne et due forme par le fournisseur et acceptée par IMIO. Afin de préserver le fournisseur, des livrables objectifs seront définis comme étapes dans la livraison du projet. Ces livrables définiront un seuil d avancement. Cet état d avancement permettra au fournisseur d émettre une facture partielle. Question 2 (p11) : Peut-on utiliser une variante pour un des deux postes du LOT 2 ou doit-on utiliser le même produit pour les deux postes (mutualisé et local)? Réponse Q2 : Le fournisseur peut se permettre de proposer deux softwares différents tant qu il conserve à l esprit que le mode opératoire et les intégrations doivent rester identiques. Il est fondamental pour IMIO de n entretenir qu une seule version de GED-Plone, qui soit commune aux installations locales et SaaS. Question 3 (p18) : Devons-nous apporter la machine virtuelle et la faire fonctionner sur du matériel mis à disposition ou devons-nous également prévoir le matériel pour faire fonctionner cette machine virtuelle. Réponse Q3 : Le matériel sera mis à disposition par IMIO pour faire fonctionner la machine virtuelle que le fournisseur doit fournir. Question 4 (p25) : Est-ce que la vitesse demandée peut être obtenue en mode landscape pour le scanner 3? Réponse Q4 : Oui, la vitesse de 90 ppm peut être atteinte en paysage. Question 5 (p25) : Est-ce que la vitesse demandée peut être obtenue en mode landscape pour le scanner 4? Réponse Q5 : Oui, la vitesse de 80 ppm peut être atteinte en paysage. Question 6 (p25) : Est-ce que la détection de double alimentation multipostions est nécessaire pour le scanner 4 ou est-ce qu une détection simple position est suffisante? Réponse Q6 : le mode de détection de double alimentation peut être une simple position pour le scanner 4 comme pour les autres scanners. Question 7 (p30) : Est-ce que le redressement sur base du contenu est nécessaire ou un redressement sur base des bords de l image est-il suffisant?

5 5/ 7 BE001 04/06/ Numéro BDA: Formulaire type 14 - FR Réponse Q7 : Notre objectif est d avoir une reconnaissance OCR la meilleure possible. L idéal pour une bonne reconnaissance OCR est un redressement sur base du contenu. Si le résultat OCR est satisfaisant avec un redressement sur base des bords de l image, alors ce mode de redressement est satisfaisant. Question 8 (p30) : Devons-nous fournir cette documentation en réponse au cahier des charges ou lors de l implémentation? Réponse Q8 : Cette documentation est à fournir au terme de la phase d analyse, après validation de la maquette, avant de débuter l implémentation. Question 9 (p31) : Pouvez-vous nous confirmer que le mode d export (vers Plone) sera identique pour l installation mutualisée et pour l installation locale et qu aucun autre type d export n est à prévoir? Réponse Q9 : Au stade actuel du projet, il est prévu d adopter un mode de fonctionnement identique pour les deux types d installation (locale et SaaS) Question 10 (p33) : Est-ce que la résolution des incidents bloquants peut être mise en place par une procédure de «Disaster Recovery» à suivre par le client avec support du fournisseur? Réponse Q10 : De prime abord, nous refusons cette méthodologie. Nous analyserons plus en détail le fonctionnement proposé par le fournisseur qui sera sélectionné et les avantages liés à ce mode de fonctionnement. S il est d ores et déjà certain qu une procédure Disaster Recovery devra être mise en place, cette dernière ne peut pas servir à résoudre un problème fonctionnel. Question 11 (p39) : Connaissez-vous le nombre de champs qui composeront une ligne de facture? Réponse Q11 : Les factures reçues par les pouvoirs locaux sont identiques à celles des sociétés, on peut donc envisager par ligne un nombre maximal de 9 champs (numéro de ligne, numéro d article, dénomination d article, quantité, prix unitaire, réduction, régime TVA, montant TVA et montant total). Le nombre moyen de colonnes étant en général de 6. Question 12 (p45) : Pouvez-vous nous confirmer qu un annuaire Microsoft Windows sera accessible? Réponse Q12 : Nous attirons votre attention sur le point que vous faites l assimilation entre 2 sections qui ne sont pas dépendantes. La page 45 traite du lot 2 en mode mutualisé. Pour ce mode de fonctionnement là, un annuaire d entreprise de type Open LDAP contiendra les membres et leurs caractéristiques. La deuxième capture d écran qui décrit les métadonnées provient du lot 1 dans lequel nous demandons au logiciel de capture ad hoc de fournir les métadonnées décrites, notamment le windows ID de la personne identifiée sur l ordinateur auquel le scanner est connecté. La plupart des postes de travail étant sous OS Microsoft, l identifiant de la personne est dénommé Windows ID, cela n implique pas que l annuaire d entreprise hébergé en SaaS soit un annuaire Microsoft Windows. Question 13 : Concernant l application à proposer dans le LOT1. Est-ce que la possibilité de définir des droits d accès à la configuration du logiciel suivant le type d'utilisateur (scan/administrateur) est nécessaire ou une plus-value? Réponse Q13 : Si votre question est de savoir si nous sommes intéressé par un «effacement» des fonctionnalités administrateurs afin d augmenter l ergonomie de l interface utilisateur, alors notre réponse est positive. En conséquence de quoi, le logiciel de capture ad hoc doit permettre d adopter une interface utilisateur différente, limitée aux fonctionnalités d utilisation, de l interface administrateur (complète avec toutes les fonctions) afin d en augmenter l ergonomie. Question 14 : Etant donné que vous précisez un mode de licence pour le logiciel de capture adhoc dépendante du type de scanner (sa vitesse) mais indépendante du modèle de scanner (multi-marque), il nous paraitrait judicieux que votre licence d'amélioration d'image suive le même modèle. Quelle est votre position par rapport à cela? Réponse Q14 : La licence d amélioration d image demandée au point V doit être indépendante de la marque & du modèle de scanner afin qu elle soit transposable au nouveau scanner lors de son remplacement. Le fournisseur explique la méthode d upgrade de la licence si le nouveau scanner devait être d une catégorie supérieure à l initiale. Question 15 (v2.3.1 p29) : est-ce que le web service est encore à développer pour la connexion avec le gestion électronique de documents ou est-ce qu'il y a déjà un web service disponible? Réponse Q15 : La technologie Web Services est déjà présente et utilisée par d autres de nos applications. Nous disposons d une plateforme WebServices Flexible qui nous permet de rapidement faire le mapping des métadonnées. Votre connecteur Web Service qui sera utilisé pour transférer les métadonnées extraites vers la GED est encore à développer. Question 16 (v2.4 p 35) : mettre les codes à barre à disposition : s'agit-il d'un fichier prêt à imprimer par IMIO ou les codes à barre eux-mêmes? Doivent-ils être livrés sur des rouleaux ou sur des feuilles A4 avec étiquettes à enlever? Réponse Q16 : Les codes barres sont à livrer au pouvoir local sur base d un formulaire de commande à définir. Les codes-barres doivent être livrés enroulés sur un cœur de carton. Si le fournisseur en dispose, il propose

6 6/ 7 BE001 04/06/ Numéro BDA: Formulaire type 14 - FR en option un dérouleur correspondant au modèle de cœur de carton proposé. Tenant compte des volumes variables commandés, le dérouleur doit pouvoir contenir différentes capacités. Toutefois, dans un souci de maniabilité, nous souhaitons limiter le nombre de codes-barres à environ par rouleau. Le format du code barre est laissé à l appréciation du fournisseur pour que la taille du code barre permette une bonne reconnaissance par le logiciel de capture adhoc. Question 17 (v3.1.4 p 39) : reconnaissance numéro de bon de commande, numéro engagement : est-ce que les fournisseurs mentionnent ces codes? Ont-ils une structure unique? Est-ce que la structure est différente pour chaque client de IMIO? Réponse Q17 : Les fournisseurs sont priés de mentionner ces références dans la facture qu ils émettent vers l administration publique. La présence de ces références est donc aléatoire et non formaté, la structure dépend de l applicatif dans lequel ces références sont générées. Ce qui est commun à tous les pouvoirs locaux est l article budgétaire. Question 18 (v3.1.4) : lignes de détail : quel est le but de la reconnaissance de chaque ligne de détail (article, quantité, prix code tva...)? La plupart des ERP ne peuvent pas traiter cette information. Réponse Q18 : La reconnaissance des lignes est une demande spécifique de certains pouvoirs locaux pour permettre un rapprochement automatique entre la facture et le bon de commande. Question 19 (v3.1.4 point 3 p 40) : exporter vers l'application comptable : s'agit-il d'un export standard? Y a-t-il un lien entre le logiciel GED et la comptabilité? Est-ce que les données reconnues de la facture doivent être injectées dans la comptabilité? Est-ce que les clients ont tous la même comptabilité? Réponse Q19 : Dans un premier temps, L export sera effectué vers les applicatifs comptables de Adéhis et Stesud qui est représentent une majorité de pouvoirs locaux. Par la suite, en fonction des demandes, il pourrait être nécessaire de permettre de développer de nouveaux exports vers d autres applications comptables. Question 20 (v3.1.7 p 41) : définir plusieurs types de ligne : est-ce que ceci signifie qu'il y a plusieurs informations différentes à reconnaitre par client/fournisseur : ex. numéro article, qté, prix ou nom, prix net, remise...? Réponse Q20 : Au delà des types d informations présentes par ligne, les fournisseurs peuvent avoir différentes types (formats) de lignes (prestations de services, fournitures de marchandises, location, maintenance, etc.) Prenons par exemple une location de photocopieur dont la location est fixe et mensuelle mais dont la maintenance est au nombre d impressions effectuées et leur taux de remplissage. Sur une même facture, différentes colonnes seront présentes entre dans les sections de la facture. Question 21 (v ) : régime TVA : que veut-on dire par ceci? Est-ce le % de tva ou le code TVA utilisé dans la comptabilité? Réponse Q21 : nous sous-entendons par là le taux ou le montant de TVA pour cette facture/ligne. Question 22 : Pouvez-vous décrire plus précisément vos attentes vis à vis de l intégration avec votre CMS «Plone». Réponse Q22 : Le CMS Plone est une couche applicative Open Source sur laquelle nous construisons nos outils Open Source (GED, Urbanisme, Meeting, Site Web, Guichet Citoyen). Cette plateforme applicative est mise en lien avec divers outils (cartographie & DGO4 pour l urbanisme, e-tutelle et DGO5 pour Plone Meeting,...). Il est important de préciser qu il y a différentes intégrations qui sont à réaliser, l intégration pour le transfert d informations (retour des valeurs extraites des factures après validation par exemple) et également l intégration pour la mise à disposition de moyens d action. Selon les informations récoltées, le processus d extraction automatisée des factures est assez semblable chez tous les fournisseurs (dématérialisation, extraction, validation, export). La dématérialisation est prise en charge par le scanner et le logiciel de scanning ad hoc. L extraction est effectuée en arrière plan (invisible de l utilisateur). La validation est une étape humaine effectuée à l aide d un composant du logiciel. Ensuite, l export est réalisé en arrière plan. La suite de l explication tient compte de notre souhait de travailler au niveau du document, non pas au niveau du lot de factures. Le processus de traitement des factures est effectué comme cela, avec cette granularité là. Ceci explique notre demande de ne pas bloquer de lot pour une facture à valider. L étape de validation, selon l approche actuellement envisagée, se déroulerait dans le CMS Plone. Afin de ne pas développer une fonctionnalité existante, nous souhaitons intégrer le module web de vérification à l étape de validation (interface web de Plone) via un reverse proxy. Cela permet aux utilisateurs de rester dans un seul environnement (Plone) pour l ensemble du processus de traitement des factures (extraction, approbation, mise en comptabilité) tout en bénéficiant de votre savoir faire et expérience. Il en va de même pour l optimisation des documents reconnus. La granularité du processus de traitement des factures est actuellement fixé au niveau du document (l entité documentaire), la validation serait donc à effectuer par document dans son processus de traitement. Dans le cas d une limitation au traitement par lot, il est évident que nous devrions ajouter une étape au processus

7 7/ 7 BE001 04/06/ Numéro BDA: Formulaire type 14 - FR envisagé. Cette étape contiendrait la validation par lot pour ensuite débuter le traitement comptable au niveau document. Cela n est pas notre scénario préféré car il ajoute une étape au processus et ne permet de débuter le traitement suivant qu après la validation de l ensemble du lot. Le scénario de redévelopper la validation entièrement dans le CMS Plone a été envisagé mais nous semble inopportun au vu des technologies actuelles existantes. Concernant l intégration de type transfert d information, nous demandons d utiliser un des standards Web Services entre votre logiciel et notre CMS Plone. Ceci également afin de maintenir une couche de transport nécessaire à la non-contamination de notre type de licence GNU GPL2. Si votre expertise vous encourage à nous proposer un autre scénario qui permette la même fonctionnalité, nous sommes ouverts à de bonnes propositions. Communication libre : Une inversion est à faire dans le bordereau de prix du lot 1. Les quantités des lignes 12 et 13 sont à inverser. Il faut lire 20 * maintenance annuelle du scanner 3 et 2 * licence d amélioration d image du scanner 3. VI.5) DATE D ENVOI DU PRÉSENT AVIS: 04/06/2013 (jj/mm/aaaa)