الجواب القصير. SaaS متعدد المستأجرين هو نسخة واحدة من الكود تخدم كل الزبائن، كلٌّ في فضاء محكم يُسمى مستأجراً. والإحكام لا يأتي من خانة تُؤشَّر: بل من المستأجر المقروء من رمز الدخول لا من العنوان أبداً، ومن معرّف مستأجر في كل جدول مع سياسات صفوف في القاعدة ترشّح حتى حين ينسى الكود، ومن اختبارات تحاول قراءة زبون آخر مع كل تسليم. بيانات العموم تتشارك قاعدة؛ والحسابان أو الثلاثة الكبيرة التي تشترط ذلك لها قاعدتها المخصصة، يُنقلها موجّه بيانات دون تغيير سطر من الكود. الخطط بيانات للمستأجر يقرؤها الكود لا نسخ مختلفة؛ والحصص تُطبَّق في طبقة التفويض؛ والترحيلات تخرج على موجات وتتراجع. ستة عشر أسبوعاً، اثنان منها لكتابة نموذج المستأجر قبل أي كود.
هذا الدليل موجّه إلى المؤسس المقيم في فرنسا الذي يريد بيع برنامج بالاشتراك لصيدليات أو مدارس أو وكالات في الجزائر، وإلى الشركة التي «كرّر» مورّدها المشروع لكل زبون فصار يصون أربع عشرة نسخة، وإلى من يقرأ «هندسة متعددة المستأجرين» في عرض سعر دون أن يعرف ما يجب أن تحتويه. لا يتناول نموذج الاشتراك ولا الدفع، الموصوفين في دليل إطلاق SaaS في الجزائر سنة 2027؛ بل يتناول ما يُبنى كي يتسع تثبيت واحد لمائة زبون دون أن يرى بعضهم بعضاً.
ما تقوله الأرقام
النصوص الثلاثة المهمة علنية. تسمّي Amazon Web Services، في عدسة SaaS من إطار Well-Architected، ثلاثة نماذج: الصومعة (silo) حيث لكل مستأجر موارد مخصصة، قاعدته مثلاً، مع تشارك الهوية والتسجيل والتشغيل؛ والحوض (pool)، «المفهوم الأكثر كلاسيكية لتعدد المستأجرين»، حيث يتشارك المستأجرون الحوسبة والتخزين والمراسلة؛ والجسر (bridge)، النمط المختلط حيث بعض الأجزاء في صومعة وأخرى في حوض، والملف التنظيمي للبيانات وخطر الجار المزعج يدفعان خدمة نحو الصومعة. وهذه المفردات تنتقل كما هي: سؤال SaaS الجزائري ليس «صومعة أم حوض» بل «ماذا في الصومعة، ماذا في الحوض، وكيف ننتقل من أحدهما إلى الآخر دون إعادة كتابة».
توثّق PostgreSQL، القاعدة التي نستعملها لأغلب SaaS، الأمان على مستوى الصفوف: ما إن يُفعَّل على جدول حتى «تُطبَّق سياسة رفض افتراضية إن لم توجد سياسة» فلا يظهر أي صف؛ والمستعملون الفائقون والأدوار الموسومة BYPASSRLS تتجاوزه دائماً، ومالك الجدول أيضاً ما لم يُفرَض؛ وتحذّر الوثائق من أن قيود السلامة تتجاوز السياسات وقد تخلق قنوات خفية. تفاصيل تقرر الأمان الحقيقي: سياسة صفوف مفعَّلة غير مفروضة، مع تطبيق متصل بصفة المالك، لا تحمي شيئاً. وتضع OWASP، في قائمتها العشر الأولى لواجهات API لسنة 2023، في المرتبة الأولى كسر التفويض على مستوى الكائنات: مهاجم يغيّر معرّفاً في الطلب فيصل إلى بيانات غيره؛ والعلاج التحقق من التفويض «في كل دالة تصل إلى سجل بمعرّف يقدّمه العميل»، وتفضيل معرّفات عشوائية غير متوقَّعة، وكتابة الاختبارات.
وحالة مارس 2026 تقولها أفضل من قاعدة. يصف إشعار أمني نُشر في 8 مارس 2026 لـOneUptime، منصة مراقبة مفتوحة المصدر، ترويسة HTTP كان العميل يستطيع وضعها بنفسه فتعطّل الترشيح حسب المستأجر؛ ومع ترويسة معرّف مشروع مختار، كان مستعمل عادي يعدّد مشاريع زبائن آخرين ويعدّلها ويقرأ تجزئة كلمة مرور منشئها ورمز إعادة تعيينه، حتى الاستيلاء على الحساب؛ درجة 9,9 من 10، أُصلحت في الإصدار التالي. وفي الجانب الجزائري ينمو الميدان: وفق مدير الشركات الناشئة بوزارة اقتصاد المعرفة على إذاعة الجزائر في 11 فيفري 2026، حصلت أكثر من 1 100 شركة ناشئة على العلامة منذ 2020، ولم تتوقف إلا نحو عشر، وتوجد علامة Scale-up منذ ديسمبر 2025، وتستهدف الوزارة نحو خمس عشرة منها في 2026؛ ومصادر أخرى تعطي أعداداً مختلفة، ونعتمد رقم الوزارة. كثير من هذه الشركات يبيع برنامجاً بالاشتراك، وهندستها هي التي تقرر إن كان الزبون المائة يكلّف بقدر الأول. ما لم نجده: إحصاء لـSaaS الجزائرية أو قياس لهندستها؛ هذا الدليل يتحدث عما نبنيه لا عن إحصائية.
حياة طلب في SaaS متعدد المستأجرين، في ست لحظات
الهندسة لا توصف بمخططات قاعدتها بل بما يحدث لطلب، من دخول مستعمل إلى سطر السجل الذي سيغذّي فاتورته.
الدخول يصدر رمزاً يحمل هوية المستعمل والمستأجر الذي ينتمي إليه ودوره فيه؛ والدخول نفسه، برقم الهاتف أو البريد، يتبع دليل المصادقة بـOTP، ويمكن للمستعمل الواحد، محاسب مثلاً، أن ينتمي إلى عدة مستأجرين ويختار واحداً عند الدخول. المستأجر المحدَّد هو اللحظة التي تقرر الأمان: يأتي من الرمز، أو من نطاق فرعي متحقَّق منه مقابل الرمز، لا من معامل عنوان ولا حقل استمارة ولا ترويسة يستطيع العميل كتابتها أبداً؛ وثغرة مارس 2026 هي بالضبط ترويسة كان العميل يستطيع وضعها. السياق الموضوع يرفق المستأجر بالطلب ويمرّره إلى جلسة قاعدة البيانات كمتغير؛ وكل ما يلي، كوداً وطوابير وملفات، يراه دون أن يطلبه مجدداً، وهذا ما يمنع السطر المنسي.
التفويض يتحقق من ثلاثة أشياء ويرفض إن غاب أحدها: دور المستعمل في هذا المستأجر، الخطة التي اشترك فيها المستأجر، والحصص المتبقية له؛ وهنا، لا في الشاشة، تُمنع الخطة الأساسية من تصدير عشرة آلاف صف. الاستعلام في القاعدة يمسّ جداول تحمل كلها عمود مستأجر، بفهرس يبدأ به، وسياسات صفوف مفعَّلة ومفروضة: إن نسي مطوّر شرط الترشيح أضافته القاعدة؛ والسياسة شبكة لا خط الدفاع الأول، وتُختبر بدور ليس مالكاً. السجل والقياس يكتبان كل عملية بمستأجرها: الاستعمال، الأخطاء، التخزين، الإرسالات؛ وهذا السجل يغذّي عدادات الحصص والفاتورة بالدينار والشاشة التي تقول أي مستأجر يستهلك ماذا، بروح دليل لوحة القيادة.
SaaS متعدد المستأجرين، في خمس طبقات
خلف اللحظات الست خمس طبقات، والوسطى هي ما يميّز SaaS عن مجموعة نسخ.
الهوية والمستأجرون: حسابات ومستأجرون وأعضاء وأدوار ودعوات، وقاعدة أن المستعمل يمكن أن ينتمي إلى عدة مستأجرين؛ ولكل مستأجر مديروه الذين يدعون ويزيلون دون المرور بالدعم. الخطط والحصص: مستويات ووظائف مفعَّلة لكل مستوى وحدود وعدادات؛ الخطة بيانات للمستأجر يقرؤها الكود مع كل طلب، لا نسخة مختلفة من الكود أبداً، وهذا ما يتيح تغيير خطة زبون في دقيقة. التطبيق: نسخة واحدة من الكود للجميع، والمستأجر سياقاً في كل طلب وكل مهمة خلفية وكل ملف مخزَّن؛ تحديث واحد يخدم الجميع، والوظائف المقصورة على مستوى مفاتيحُ لا فروعُ كود.
البيانات: قاعدة مشتركة بسياسات صفوف للعموم، مخطط أو قاعدة مخصصة للحسابات الكبيرة التي تشترطها، موجّه يعرف أين يقيم كل مستأجر، وأياً كان النموذج فالنسخ الاحتياطي والتصدير وحذف المستأجر عمليات وحدوية. التشغيل: نشر واحد، ترحيلات على موجات، إشراف لكل مستأجر وحماية من الجار المزعج، طوابير عمل وحدود تدفق لكل مستأجر؛ نعرف أي مستأجر يستهلك ماذا ونعزله قبل أن يبطئ الآخرين. الطبقات السفلى تقرر تكلفة التشغيل التي يصفها دليل حياة التطبيق؛ والطبقات العليا تقرر ما يمكن بيعه، ودليل SaaS في 2027 يصف كيف يُباع.
«SaaS هو نسخة واحدة من الكود والمستأجر سياقاً في كل مكان؛ وكل ما عداه مجموعة نسخ ينتهي الأمر بألا يجرؤ أحد على مسّها.»
مثال محسوب
مثال على فرضيات سوق، بآلية ليست فرضية: SaaS عمودي بعد سنتين من الإطلاق.
120 زبوناً نشطاً على تثبيت واحد: صيدليات وعيادات ومتاجر، لكلٍّ مستعملوه وبياناته وإعداداته، ولا أحد يعرف أن الآخرين موجودون. 3 خطط، أساسية واحترافية ومؤسسات: الوظائف وعدد المستعملين والتخزين وإرسال الرسائل تأتي من الخطة؛ ونقل زبون من الاحترافية إلى المؤسسات كتابةٌ في بطاقته لا نشر. زبونان على قاعدة مخصصة: مجموعة مصحات وموزّع اشترطاها في العقد، للاستعادة المستقلة والفصل الظاهر؛ نقلهما موجّه البيانات خارج القاعدة المشتركة في عملية واحدة دون أن يتغير سطر من الكود، ويدفعان خطة المؤسسات التي تغطي هذه التكلفة الثابتة.
صفر تثبيت لكل زبون هي النتيجة التي لا تتوقف على أي فرضية: تحديث واحد أسبوعياً، نفسه للـ120، يُنشر في دقائق، بترحيلات مختبرة على نسخة من الإنتاج ومنشورة على موجات؛ زبون للقراءة فقط ثلاث دقائق، لا مائة زبون يُحدَّثون واحداً واحداً. ما يُظهره المثال: بالمستأجر كسياق يكلّف الزبون المائة والعشرون سجلاً في القاعدة وسطراً في الإشراف؛ وبنسخة لكل زبون يكلّف خادماً ونشراً ومكاناً في قائمة ما لا يجرؤ أحد على مسّه. الفرضيات التي تُتحقَّق عندكم: كم زبوناً، أي حصة ستشترط قاعدتها، وكم مستعملاً لكل زبون؛ والأسبوعان الأولان من المشروع يجيبان عنها.
ست طرق لإيواء بيانات الزبائن
ستة نماذج، ومعيار واحد للحكم عليها: لا يجوز لأي منها أن يغيّر كود التطبيق.
القاعدة المشتركة بصفوف محمية هي الحالة الافتراضية، من عشرات إلى آلاف الزبائن بحجم عادي: عمود مستأجر في كل جدول، سياسات صفوف مفعَّلة ومفروضة، واختبار مع كل تسليم يحاول قراءة مستأجر آخر ويجب أن يفشل. المخطط لكل زبون يعطي فصلاً ظاهراً دون قاعدة مخصصة؛ يفرض تكرار كل ترحيل على كل مخطط وإدارة الاتصالات، ويقول الممارسون إنه يثقل بعد بضع مئات من الزبائن؛ ونحتفظ به للحالات التي يريد فيها زبون رؤية فصله دون دفع ثمن قاعدة. القاعدة لكل زبون هي صومعة AWS: حسابات كبيرة، بيانات منظَّمة، عقد يشترطها، حاجة إلى استعادة زبون واحد؛ تكلفة ثابتة لكل زبون، نسخ احتياطية وترحيلات مضاعفة، وموجّه يعرف أي قاعدة تخدم أي مستأجر.
نسخة التشغيل لكل زبون تذهب أبعد: خادمه ونطاقه وأحياناً بلد استضافته، لكن الهوية والتحديث والإشراف تبقى مشتركة، وإلا لم يعد SaaS بل سلسلة مشاريع، ودفع الاستضافة بالعملة الأجنبية يتبع دليل دفع تكاليف السحابة من الجزائر. المختلط هو الحالة الحقيقية لأغلب SaaS بعد سنتين: العموم يتشاركون، وحسابان أو ثلاثة كبيرة معزولة، وطبقة البيانات وحدها تعرف أين يقيم كل واحد؛ وهو جسر AWS، وهو ما يصفه المثال المحسوب. التثبيت عند الزبون نادر، إدارة أو مجموعة ترفض السحابة؛ حزمة قابلة للتثبيت وإصدارات تُتابَع ودعم مختلف، يُفوتَر على هذا الأساس. السطر الأول يغطي أغلب SaaS الجزائرية في 2027؛ والخامس ما تصير إليه حين يوقّع حساب كبير.
ست حالات تكسر SaaS متعدد المستأجرين
ست حالات نراها في SaaS التي نستلمها، وما تفعله الهندسة ضد كل منها.
التسرّب بين الزبائن يكلّف الثقة: مستعمل يغيّر معرّفاً في العنوان فيرى فواتير زبون آخر؛ المستأجر المقروء من الرمز، والتحقق عند كل كائن، وسياسات الصفوف كشبكة، ومعرّفات عشوائية، واختبار آلي يحاول التسرب مع كل تسليم تجعله مستبعداً، وهذا الترتيب الذي توصي به OWASP. الجار المزعج: زبون يطلق تصدير مليوني سطر الساعة العاشرة فيبطئ الجميع؛ طوابير عمل لكل مستأجر، حدود تدفق، تصدير غير متزامن يُسلَّم برابط، حصص لكل خطة، تنبيه لكل مستأجر. الترحيل الذي يكسر زبوناً: تغيير مخطط يمرّ لـ119 زبوناً ويفشل عند الـ120 الذي لديه بيانات قديمة؛ ترحيلات مختبرة على نسخة من الإنتاج، منشورة على موجات، قابلة للتراجع، والزبون للقراءة فقط مدة الترحيل.
الزبون الذي يريد بياناته يغادر أو يريد نسخة أو يريد محو كل شيء؛ تصدير كامل لكل مستأجر بصيغة مقروءة، حذف مستأجر في عملية واحدة مسجَّلة، ومهلة مكتوبة في العقد، وهو ما يطلبه أيضاً دليل التطبيق العالق عند مطوّر اختفى لبياناتكم أنتم. الحساب الكبير الذي يشترط قاعدته يوقّع بشرط قاعدته ونطاقه وأحياناً بلد استضافته؛ ينقله موجّه البيانات دون مسّ الكود، وخطة المؤسسات تدفع التكلفة الثابتة. الخطة التي لا تحدّ شيئاً: الخطة الأساسية تستهلك من التخزين والإرسال بقدر خطة المؤسسات، وترتفع التكاليف مع الزبائن الأقل دفعاً؛ عدادات لكل مستأجر يغذّيها السجل، حدود مطبَّقة في طبقة التفويض، تجاوز ظاهر للزبون مع زر تغيير الخطة. الأولى تكلّف الثقة، والخمس الأخرى تكلّف مالاً أو زبائن، ولا تُصلَح أي منها في الطوارئ.
«المستأجر يأتي من الرمز، ولا من أي شيء يستطيع العميل كتابته.»
رأيناه في مكان آخر: AWS وPostgreSQL وOWASP وOneUptime، وما ينتقل
أربعة نصوص علنية تقول الجوهر. AWS تعطي المفردات، الصومعة والحوض والجسر، وقاعدة أن القرار يُتخذ مورداً مورداً لا للنظام كله؛ وما ينتقل هو أن يُقرَّر في الأسبوع الأول ما يُتشارك وما يُعزل، وأن يُبنى موجّه البيانات الذي يتيح تغيير الرأي لزبون واحد دون إعادة كتابة. وPostgreSQL تقول ما تساويه سياسة الصفوف: كل شيء مرفوض افتراضياً ما إن تُفعَّل، والمستعملون الفائقون والمالك يمرّون ما لم تُفرَض، وقيود السلامة قد تسرّب؛ وما ينتقل هو أن يتصل التطبيق بدور ليس مالكاً، وأن تُفرَض السياسة، وأن يتحقق منها اختبار بذلك الدور نفسه.
وOWASP تقول أين ننظر: معرّف الكائن الذي يقدّمه العميل هو السبب الأول للتسرب بين الزبائن، والجواب تحقق عند كل وصول ومعرّفات غير متوقَّعة واختبارات؛ وما ينتقل هو أن «متعدد المستأجرين» في عرض سعر يجب أن يرافقه «اختبارات تسرب بين المستأجرين مع كل تسليم». وحالة OneUptime في مارس 2026 تقول الشكل الذي يتخذه الخطأ في الواقع: لا قاعدة سيئة التصميم، بل ترويسة يستطيع العميل وضعها فتعطّل الترشيح؛ وما ينتقل هو قاعدة اللحظة 02، المستأجر يأتي من الرمز ولا من شيء آخر. وما لا تقوله هذه النصوص: أي حصة من زبائنكم ستشترط قاعدتها، وبأي سعر تبيعونها؛ وتجريب الأسبوع 12 ودليل SaaS في 2027 يجيبان عن ذلك.
قواعد SaaS متعدد المستأجرين الذي يصمد
ست قواعد تُكتب في الأسبوع الأول وتُعاد قراءتها مع كل تسليم. نسخة واحدة من الكود: الخطط مفاتيح تُقرأ من بطاقة المستأجر لا فروع أبداً؛ ووظيفة يطلبها زبون تُبنى للجميع وتُفعَّل له. المستأجر يأتي من الرمز، أو من نطاق فرعي متحقَّق منه مقابل الرمز، ولا من أي شيء يستطيع العميل كتابته. كل جدول يحمل المستأجر، والفهرس يبدأ به، وسياسات الصفوف مفعَّلة ومفروضة ومختبرة بدور التطبيق. اختبار تسرب مع كل تسليم: مستعمل من المستأجر أ يحاول القراءة والتعديل والحذف في المستأجر ب عبر كل نقاط الدخول، ويُرفض التسليم إن نجح مرة. عمليات كل مستأجر موجودة قبل الزبون الأول: تصدير وحذف واستعادة ونقل إلى قاعدة مخصصة. الحسابات والكود والنطاقات والاستضافة باسم الشركة لا المورّد، والكود يُسلَّم في مستودع تملكونه.
قاعدة سابعة تخص دفتر الشروط: «هندسة متعددة المستأجرين» ليست متطلباً بل جملة؛ المتطلب يُكتب «نسخة واحدة من الكود تخدم كل الزبائن؛ المستأجر يُحدَّد من الرمز؛ كل جدول يحمل tenant_id بسياسات صفوف مفروضة؛ اختبار آلي للتسرب بين المستأجرين جزء من القبول؛ تصدير المستأجر وحذفه ونقله إلى قاعدة مخصصة عمليات مسلَّمة؛ الخطط والحصص تُطبَّق في طبقة التفويض»، ويُتحقَّق منه عند القبول كما يوصي دليل دفتر الشروط. وعرض السعر الذي يكتب «متعدد المستأجرين» دون هذه الأسطر الستة سعّر تطبيقاً لزبون واحد سيُنسخ.
ستة SaaS عمودية، ما يُتشارك وما يُعزل
ستة SaaS نبنيها كثيراً، ولكل منها نموذج البيانات المختار في الأسبوع الأول.
- SaaS للصيدليات أو المتاجر. قاعدة مشتركة، مستأجر لكل صيدلية، ثلاث خطط؛ والتكامل مع صندوق كل زبون ومحاسبته يتبع دليل دمج البرامج القائمة، بموصل لكل مستأجر.
- SaaS للمدارس الخاصة. قاعدة مشتركة، مستأجر لكل مؤسسة، أولياء ينتمون إلى عدة مستأجرين حين يكون لهم أبناء في مدرستين؛ تصدير كامل مطلوب في كل نهاية سنة.
- SaaS للمصحات والعيادات. قاعدة مشتركة للعيادات، قاعدة مخصصة للمجموعات التي تشترطها؛ سياسات صفوف مفروضة وسجل وصول لكل مستأجر، لأنها بيانات صحية.
- SaaS للوكالات العقارية. قاعدة مشتركة؛ مالك في فرنسا يمكن أن يكون عضواً في عدة وكالات؛ وفضاء المالك الموصوف في الدليل المخصص عرض مرشَّح بالمستأجر وبالعقار.
- SaaS للموزّعين. قاعدة مشتركة لأغلبهم، نسخة تشغيل مخصصة للمستورد الذي له ERP ونطاقه؛ وبوابة B2B لكل موزّع، الموصوفة في الدليل المخصص، مستأجر تجّارُه أعضاؤه.
- SaaS بوكيل ذكاء اصطناعي. وكيل WhatsApp لكل مستأجر على المنصة نفسها، رقم وقوالب باسم كل زبون، معارف وسجلات مفصولة لكل مستأجر؛ وهندسة الوكيل تتبع الدليل المخصص.
تقويم 2027
التقويم تقويم SaaS متعدد المستأجرين في ستة عشر أسبوعاً، اثنان منها بلا كود واثنان للتجريب مع خمسة زبائن حقيقيين على التثبيت نفسه.
الأسبوعان 0 إلى 2 يكتبان نموذج المستأجر: ما المستأجر، من العضو، أي أدوار، أي خطط بأي حدود، أي نموذج بيانات افتراضي وأي مسار إلى القاعدة المخصصة؛ وSaaS يُكتب نموذجه بعد الكود يصير مجموعة نسخ. الأسبوعان 2 إلى 4 يبنيان الهوية: تسجيل مستأجر، دعوات، أدوار، دخول بالهاتف أو البريد، انتماء إلى عدة مستأجرين. الأسابيع 4 إلى 8 تبني جوهر العمل بالمستأجر في كل مكان: عمود مستأجر في كل جدول وكل طابور، سياسات صفوف مفروضة، واختبار التسرب الذي يدور مع كل تسليم منذ الأول. الأسبوعان 8 إلى 10 يضعان الخطط والحصص والفوترة: مستويات، مفاتيح لكل مستوى، عدادات، تجاوزات، فواتير بالدينار وتذكير قبل الاستحقاق، على النموذج الموصوف في دليل SaaS في 2027.
الأسبوعان 10 إلى 12 يثبّتان التشغيل: ترحيلات على موجات، نسخ احتياطي وتصدير لكل مستأجر، إشراف لكل مستأجر، حدود تدفق، وموجّه البيانات مختبَراً بنقل مستأجر تجريبي إلى قاعدة مخصصة والعودة. الأسبوعان 12 إلى 14 هما التجريب: خمسة زبائن حقيقيين على التثبيت نفسه، الاستعمال مقاساً لكل مستأجر، وأول حساب كبير معزول إن اشترطه أحد الخمسة؛ وهي أول لحظة يتشارك فيها زبونان القاعدة نفسها فعلاً. الأسبوعان 14 إلى 16 يفتحان: تسجيل ذاتي، إدماج آلي، أول خطة مدفوعة، إشراف روتيني. والشركات الناشئة التي تستهدف العلامة، الموصوفة في دليل علامة الشركة الناشئة، خير لها أن تصل إلى الملف بهذا التجريب منجزاً لا بنموذج أولي.
ما يُفشل SaaS متعدد المستأجرين
SaaS التي نستلمها تفشل دائماً تقريباً لأحد هذه الأسباب.
- نسخة من الكود لكل زبون. نال الزبون الثالث وظيفته، وللرابع عشر نسخته؛ ولم يعد أحد يستطيع تحديث كل شيء.
- المستأجر في العنوان أو في ترويسة. معرّف يتغير فيرى زبون زبوناً آخر؛ هذه ثغرة مارس 2026، ولا تُصلَح إلا بإعادة كتابة التفويض.
- سياسات صفوف مفعَّلة غير مفروضة. يتصل التطبيق بصفة المالك فيمرّ؛ والأمان لا يوجد إلا على الورق.
- لا اختبار تسرب. يُكتشف التسرب حين يكتبه زبون على الشبكات لا عند القبول.
- الخطة كنسخة من الكود. ثلاث خطط، ثلاثة فروع، وكل تصحيح يُنجز ثلاث مرات.
- لا تصدير ولا حذف لكل مستأجر. أول زبون يغادر يستغرق ثلاثة أسابيع لاستعادة بياناته ويخبر الآخرين جميعاً.
- الحساب الكبير يُعالَج بنسخة. يُكرَّر SaaS له؛ وبعد ستة أشهر صارت له نسخته وأخطاؤه.
أسئلة شائعة
الأسئلة التي نتلقاها من مؤسسين مقيمين في فرنسا وشركات تستلم برنامجاً منسوخاً وفرق تقارن عروض الأسعار.
- متعدد المستأجرين أم تثبيت لكل زبون: أيهما نختار؟
- متعدد المستأجرين لكل SaaS يُباع بالاشتراك: نسخة واحدة من الكود، المستأجر سياقاً، وموجّه بيانات يتيح منح قاعدة مخصصة للزبونين أو الثلاثة الذين يشترطونها. أما التثبيت لكل زبون فمنتج مختلف يُفوتَر على هذا الأساس، ولا يجوز أبداً أن يكون جواباً على طلب وظيفة.
- قاعدة مشتركة أم قاعدة لكل زبون؟
- قاعدة مشتركة بسياسات صفوف مفروضة افتراضياً للعموم؛ وقاعدة مخصصة للحسابات الكبيرة والبيانات المنظَّمة والعقود التي تشترطها، يُنقلون بموجّه البيانات دون تغيير الكود. أغلب SaaS الجزائرية تنتهي مختلطة بعد سنتين، وعلى الهندسة أن تتوقع ذلك من الأسبوع الأول.
- كيف نتأكد أن زبوناً لا يرى بيانات آخر؟
- بأربع طبقات تتراكم: المستأجر المقروء من الرمز لا من الطلب أبداً، التحقق من التفويض عند كل كائن، سياسات الصفوف المفعَّلة والمفروضة في القاعدة بدور تطبيقي ليس مالكاً، واختبار آلي يحاول التسرب مع كل تسليم. وعرض السعر الذي لا يذكر الاختبار لم يخطط للثلاث الأخرى.
- زبون يطلب وظيفة لا يريدها الآخرون. هل ننسخ؟
- لا: تُبنى الوظيفة في النسخة الواحدة وتُفعَّل لهذا الزبون بمفتاح خطة أو مستأجر. وإن كانت خاصة فعلاً فوتِرت كتطوير وفُعِّلت له وحده؛ ويبقى الكود واحداً. فالنسخ هو ما يحوّل SaaS إلى أربعة عشر مشروعاً.
- ماذا يحدث حين يغادر زبون؟
- يتلقى تصديراً كاملاً لبياناته بصيغة مقروءة، ويُحذف مستأجره في عملية واحدة مسجَّلة ضمن المهلة المكتوبة في العقد. وهاتان العمليتان موجودتان قبل الزبون الأول؛ وهما الدليل على أن البيانات كانت مفصولة فعلاً.
- كم من الوقت لبناء SaaS متعدد المستأجرين؟
- ستة عشر أسبوعاً لـSaaS عمودي، اثنان منها لكتابة نموذج المستأجر قبل أي كود، أربعة لجوهر العمل بالمستأجر في كل مكان، واثنان للتجريب مع خمسة زبائن حقيقيين على التثبيت نفسه. ويُحضَّر نموذج الاشتراك والدفع بالتوازي.